1. 15

  2. 9

    I kinda see the point you’re trying to make, but there’s two contexts that I think are important to separate, and you kind of do it anyway in your article: “For money” coding, and “for fun” coding. I think you’ll find in our weekly “what’s up” thread that it’s not unusual for people to talk about those two in a cleanly separated manner.

    There’s a great learning value in toy projects, first off. New languages, new frameworks, new systems, whatever: I’ve found, in my humble few years of experience, that learning something usually changes the way I code, ever so slightly. The more foreign it is to my experience, the better.

    On another hand, there’s also the value of useful shortcuts. Depending on where you plug it in, and a plethora of other factors, I think the makefile approach described in your article is absolutely fine – for certain cases. When doing actual professional work, time is definitely a consideration. The makefile approach would take all but five minutes to achieve, and it fullfills 90% of the requirements. I would definitely consider this for a production system for actual paying customers; especially if that feature is not excessively valuable to them. Of course, if you promise them a state-of-the-art magical PDF-making machine, that’s another story.

    I think “stop writing software” is a bit broad of a statement; “start writing the right software” is probably better.

    1. 5

      Agreed on all points.

      I read once that “It’s not engineering if there isn’t money in the equation somewhere”, and since time is money, once could conclude that we aren’t doing software engineering if our approaches don’t take into account cost and timeliness.

      1. 4

        Thanks for the suggestion, I tweaked the title accordingly.

        1. 1

          I would argue that all the stuff you’re doing “for fun” is ultimately improving your future “for money” coding ability. I really agree with the “start writing the right software” prescription, though.

          1. 3

            The difference between “for fun” and “for money” is that when I do things for fun, I (figuratively) go wild and try lots of things, just for the sake of learning. Whereas in my working hours I try to take intelligent shortcuts, in my fun hours I try to take intelligent detours.

            1. 1

              I really liked that phrasing!

        2. 6

          This article seems written to create a bunch of anxiety without any actual solutions.

          Don’t write code just because it’s fun—instead, solve the problem the right way

          Ok, what’s the right way? According to the article, sometimes it’s this, sometimes it’s that, but I’m not going to tell you how to pick!

          But when you’re working, when you’re trying to get a product shipped, when you’re trying to get a bug fixed: be a professional

          I definitely wouldn’t want to be unprofessional if I want to keep my job… what should I do?? The article doesn’t even tell me what professionalism is - except definitely don’t have fun at work!

          1. 1

            I’m sorry this made you anxious.

            But here’s the thing: there are no answers. There are no rules. There’s a reason my blog is called “Code Without Rules”: I can’t tell you what to do, because it all depends on the circumstances you’re in.

            When we’re just starting out as programmers we get a spec and we implement it. And that’s comforting: we know exactly what we need to do. But beyond a certain point we end up having to design things ourselves, make the big choices on our own. And when we do, there are no rules, no easy answers. There’s only different circumstances with different solutions.

            There are principles, yes: “how fun something is shouldn’t be the main criteria when designing something at work” was the point I was trying to get across. And as is the case with every post I write, people here on Lobsters point out exceptions, because—there’s no rules.

            Pretty much everything I’ve written over past year is attempt to try to get principles rather than rules across, and it’s hard. Again, I’m sorry if I didn’t do as well as I could have in this case.

            1. 1

              I’m sorry, I shouldn’t have been so snarky.

              I fully agree that making good technical decisions in the context of a business is subtle and takes years of experience to learn to do well.

              My issue is that the article really adds no value other than pointing out the problem. What makes it worse in my opinion is that the main point is obscured behind moralizing and patronizing language that could make the kind of people who would benefit from the message (young/inexperience) more confused and stressed out than helped.

              1. 1

                I think it’s useful to point out problems, because if you don’t know a problem exists you won’t even think about the solution. In this case simply being aware of the problem seems like it would help solve it, in part. But please share you have suggestions for better solutions, or rather better ways of making the solution easier to follow.

                Could you point out specific or sentences that you felt was patronizing/moralizing? Definitely don’t want to do that, so good to know what things came across that way. Well, I guess I do want to come across as moralizing in that I think programmers have a professional responsibility to users and customers. But not in an off-putting way, so examples of where I didn’t do well would be welcome :)

                1. 1

                  The two sentences I highlighted are the most obvious offenders.

                  Don’t tell someone to do something “right” without defining right. In a technical or work situation I would almost never use the expression “right way to do something” because it’s so loaded. Be specific about what you want to be done in what way. Instead of using a right/wrong dichotomy, explain the specific benefits or costs.

                  “Be a professional” is similar. Calling into question someone’s professionalism is very harsh, particularly as you mention that you’re bringing something up many people might not even have considered before.

                  What I think would have made this article come off as more helpful would be if you discussed actual tradeoffs you might want to consider when deciding how to solve a problem. E.g., if you use a library, it could save a lot of time, but too many dependencies are hard to manage. Writing tests can be boring or slow development in the short term, but if it saves your coworkers from being at the office on the weekend fixing your mistake, then maybe it’s worth it.

                  1. 1


          2. 3

            The article starts with “We are paid to solve problems, not write code” and ends with “I would never do such hacks for production environments”. Unless you’re being paid to work on hacky sideprojects, doesn’t that mean that not only we are paid to write code, but good, maintainable code nonetheless?

            1. 6

              I would say that no, we’re not paid to write good maintainable code. We’re paid to solve problems.

              For example, I was part of a team that built the same product twice:

              First, as proof of concept demoware (this was used to raise investment money, cause it showed we could actually do something no one else could, even if not well). It had no error handling, for example, and ran as command-line scripts driven by ssh.

              Second, the product was rebuilt for actual users, with a different goal of being production-ready. And this time we used tests and a real distributed systems architecture and so on.

              Same product, different goals, and therefore different means. Good code is code that solves a problem, and sometimes the problem is “show investors we can do this, ASAP before we run out of money.” And so speed of delivery is what matters. And sometimes the problem is “production-ready product for users”, and then you need maintainable, well-tested code.

            2. 2

              I find that quick hacks like this always come to bite me, and usually at the worst possible time. I’m all about solving the problem as cheaply as possible, but fragile solutions are a false economy.

              1. 1

                This is a quick hack that is only applied by me when I manually generate a PDF, and which I can visually verify. I run this a few times a week at most.

                It will break eventually, yes. But then I will notice it and fix it. I would be surprised if it broke more than twice a year. So that’s 10 minutes/year. Compared to 4 hours+ of doing it “the right way”? Not worth it.

                OTOH, in system used by multiple people on ongoing basis the breakage would have higher cost, and would happen much sooner and much more frequently. So it would be worth fixing in less hacky way.

                1. 1

                  I’ll go out on a limb to say that even a hacky regex substitution can be production-viable. It’s there in the Makefile, everyone can see it and all the devs can be told this is the (current) state of things.

                  If it was done in code, eg. a Python class, a test case could, nay, should, check the substitution worked. Then if an external component changed its API, it would get caught.

                  And of course the obligatory disclaimer that not all hacks are equal and that it’s this one and its kind that can be justified etc etc etc.

                  1. 1

                    That’s reasonable, given pinning of all software. I do have Makefiles and Dockerfiles doing ugly stuff because there’s no real way to do it nicely.

                    But still, if I were working for a company doing book publishing I’d have done this with a patch upstream, just because it’s one use case out of many and I’d expect the hacks to accumulate.

                2. 1