6 ms·

When will programmers grow up? (2014)

• thrower123 5y ago
  Someday, the average programmer won't have less than five years of experience. Maybe. Probably not, since the ever-expanding demand for software shows no evidence of slowing, and the churn of people getting out doesn't seem liable to stop either.
• commandlinefan 5y ago
  "I see construction workers wasting time putting on hard hats when I haven't once seen something fall on their heads. When will they grow up?" "I see electricians making sure they're properly grounded before working on high voltage electrical equipment rather than just making sure they don't touch the dangerous parts while they're working. When will they grow up?" "I see pilots going through the same checklist they went through the last time they flew the plane even though they never find anything wrong. When will they grow up?" "I see lifeguards wearing buoys on their feet rather than just swimming right to begin with. When will they grow up?" Programming suffers from a lack of attention to quality not a lack of awareness that we "solve business problems".
  • majormajor 5y ago
    Most of the architectural wankery that happens in the real world does nothing to improve security or reliability of a project, though. People love to spend time discussing how to organize the code for potential future maintenance that then becomes irrelevant when requirements change, and didn't prevent someone from missing security vulnerabilities in an outdated version of a third party library anyway. So it's hard to compare that to pilots following a checklist or workers wearing helmets. Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late.
    • digbybk 5y ago
      I wouldn't expect the pilots to spend an hour debating before every takeoff, but rather to have had that debate ahead of time and have a solid set of patterns that they follow so they don't have to reinvent the wheel each time. The fact that attention to code doesn't prevent all problems doesn't mean that it doesn't prevent some problems.
    • mtdewcmu 5y ago
      The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that.
      • phkahler 5y ago
        >> The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that. I have an intern writing and app for internal use. He's using Python, tkinter, and one pip-install package for talking on modbus. Deployment to our hand full of users is easy. Low number of dependencies. It's going really well. A few days ago he said "I really would have liked to use ZZYXX-web-whatever for the GUI instead of tkinter". I said "you users don't give a fuck about that but keeping dependencies easy to manage is important". Users don't actually care about dependencies either, but they do care when it negatively affects getting the thing up and running (or slows development or...). His main gripe with tkinter was actually a lack of familiarity. I said "dude, a large part of your job is going to be learning. Get used to it." Many architectural decisions in software are completely arbitrary and don't matter nearly as much as some people think. That's not to say all such decisions, but really a lot are not a big deal. In those cases KISS trumps most preferences and big ideas. IMHO of course.
        • mcguire 5y ago
          Just when I'd lost all hope for the future... Thank you!
    • Jtsummers 5y ago
  • deleted 5y ago
    [deleted]
  • egor2820 5y ago
    Electricity, building houses is based on hard science, code quality is base on opinion
    • tehjoker 5y ago
      Those guys had to have unions to fight for safety practices. It's to protect the workers. This code quality stuff is about various competing business objectives and now annoying stuff is. I've never seen a programmer be dismembered from a missing test though I'm sure such things happen in embedded systems and robotics. Tesla Autopilot or the Uber self-driving accident in Arizona are great examples of programming leading to deaths. I guess if your Uber app doesn't work in the rain that is bad. It's when people are making safety critical decisions that this stuff matters more.
    • Bancakes 5y ago
      RAM and CPU usage is not an opinion.
      • Brian_K_White 5y ago
        Of course it is. You can prioritize cpu or ram or disk or network or developer or user resoures for the sake of the others in countless mixes and for countless mixes of reasons.
    • jk20 5y ago
      Rubbish, coding is hard science, business is snake oil salesmanship.
  • throwawayboise 5y ago
    Most programming tasks don't involve the life safety issues you are using as examples. It is certainly true that overdesign up front can be fatal to the finances of a project. There is even a term for people who engage in this, "architecture astronauts" The point is to know what you are working on, and what the customer needs. If they need one or two simple data stores and a couple of web pages, you don't need to spend weeks talking about it.
  • marcosdumay 5y ago
    It's funny because the article starts with a series of factors that the author claims to reduce code quality, and then goes to conclude that the project suffers from excess of quality. And then ends it claiming that quality is something that slows down development...
• flavius29663 5y ago
  I think the author doesn't make the distinction between *knowing* practice XYZ and effectively applying XYZ. As with anything, when we discover something new, e.g. a hammer, everything looks like nails. As a professional, I expect you to be able to argue both ways, to understand how much XYZ you need, or why XYZ has downsides and how it could hurt the company. This is not just about best practices, but about anything: libraries, programming languages, clouds, DBs etc.
• procarch2019 5y ago
  My first boss once asked me in a performance review if I was a perfectionist. I was and told him so. He then explained something that left an impression on me: the value of shipping something that works even if it’s not elegant. I think there’s a happy medium between getting stuff done and getting stuff done ‘the right way.’ A lot of young engineers seem to miss the forest for the trees and this can be seen early in a project’s timeframe. Sometimes customers don’t help either because they lack the vision to know what they are really asking for as well. I know there’s a problem when people start suggesting solutions, elegant or otherwise, before the user requirements are fully fleshed out. I work in an industry where CI/CD isn’t really a thing due to qualification/validation, so getting things perfect for re-using or servicing codebase is really inconsequential, but you’ll see people fall into the trap of ‘this has to be genericized 100% so we can use it everywhere.’ In reality nothing really gets re-used in such a way that it’s effective in reducing effort. I’m not saying it’s that way for everyone, but in my company’s pseudo programming space this is true.
  • skytreader 5y ago
    This. Clean and correct, but correct above all else. A correct solution, even when not clean, isn't going to earn money. No one (except perhaps textbook publishers) will pay for a solution that is clean alone. You can clean up a correct solution at a later date, all the while maintaining correctness; a clean (but incorrect) solution might need to be completely redesigned to make it correct. I've come to accept that the best engineers are those who ship (you don't get to 10x productivity if you don't ever ship) and that often means being able to call the correct compromises to make. Heck, I'd even say engineering in general is finding a working compromise given a set of constraints.
    • heavenlyblue 5y ago
      > often means being able to call the correct compromises to make The fact that you redefined “clean solution” as “correct compromises” doesn’t say much unfortunately.
      • 5y ago
• chexx 5y ago
  I don't think the author has to divide writing good (quality) with being slow (speed), and writing fast with being bad. I firmly believe that the goals is aligned on both sides. Client wants a feature "just works" by a certain date, and programmer wants to ship that very feature (without breaking anything else) on that certain date. The impedance mismatch is that programmers see (code) quality as enabling higher velocity (work on new features without needing to maintain old ones) with the trade-off being the upfront cost. The client sees that the time it takes to deliver feature X as being proportional to delivering feature Y and Z. The catch is that it is very hard to communicate that delivering feature Y and Z would be quicker (or not needed) if feature X was designed properly. This is because you can only approach this in hindsight (orthogonal thought: this is why upfront waterfall fell out compared to iterative agile). The hard truth both sides don't want to admit is that the programmer does not know what they are building and the client does not know what they are asking. Instead of the client wishing that the programmer had more domain experience and the programmer wishing the client had more technical experience, there should just be a stronger focus on empathy and letting things fail as part of the process. I find it interesting that when things fail, client knows exactly what failed and programmer knows exactly why it failed. Must have something to do with hindsight :)
  • procarch2019 5y ago
    Yes. I agree with this whole heartedly. It’s usually an issue with not understanding the other side’s perspective. Experienced/good engineers who know the space they are operating in can get a better sense of what the customer wants even when the customer may fail to adequately express their needs. It always helps when there’s people on both sides who have clear visions and a means to communicate those ideas with their counterparts.
• courtf 5y ago
  There is a certain zealousness that comes with learning new things and looking for ways to apply them. Any programmer likes to do this regardless of experience or maturity, so it's a little inaccurate to say programmers need to grow up, although perhaps a reduction in zealotry would be good. Often workplaces don't provide programmers, especially new programmers, the opportunity to flex their new skills as they are learned. It's rare for the business to be able to function as an incubator for programming talent when there are tickets to be closed. So, we can encourage ambitious learners explore in their free time, or we can decide for ourselves to take the subversive route and shoehorn our new skills into projects to satisfy our own desires. I am not so critical of the subversive route, it can be a great source of motivation and the business doesn't need to get everything it wants all the time, the programmer can take something for herself once in a while. In the absence of a genuine dialogue with management about helping the programmer grow, it may be quite justified to behave this way. That said, there might be a better way that involves reducing the focus on "efficiency" that has "optimized" a lot of exploratory work out of existence. There are things like 20% time and such, but getting a programmer to focus 100% on their fresh ideas is difficult for just one day a week. The cost of context switching etc. After working in a variety of small companies that were able to leave time on the table for programmers to dabble in personal interests, I have become quite skeptical of large, rich companies that don't seem to have the ability to create slack in their processes. Too much management, too much over-optimization, too many meetings and sync-ups and arbitrary metrics and other nonsense have been foisted on the workplace by various snake oil salesmen who then clog the hierarchy and continually meddle in processes with vain attempts to justify their existence. The solution isn't obvious, even the useless need jobs after all, but a lot of this frantic over-analysis is driven from the top. The need to constantly react to the market, respond to threats and opportunities, change directions 100+ times over the course of a year as leadership squabbles over who has the reins, everyone trying to build a name for themselves as quickly as possible no matter the collateral damage etc etc. The programmers aren't the only ones who need to grow up... If a workplace could manage to cultivate calm and focus from the top (easier when you aren't in the red, of course), we might be able to allow programmers the space they need to grow as individuals, while simultaneously making the most pragmatic technology decisions needed by the business.
  • 5y ago
• mcguire 5y ago
  "It appeared that last couple of weeks were spent for designing domain model and database scheme (wat?). And they were not there yet! I started to be involved in all this designing and I found that every team member suggested their vision of the model. And here comes the discussion.. That discussion was overwhelmed with buzz-words like “Best Practices”, “OOD”, “Performance” and in the end they chose the most complex scheme suggested." So I'm waiting for the part where somebody demonstrates "good programming skills"...? "I recall working for a small company where I was asked to write a tiny project to mix some videos, list them and show them to the users who can vote. The project had a budget for 2 months and I could’ve make it! But I was too blind because of good practices and maintainability. I introduced complex technologies, caching; of course I split the project into different layers and added a lot of extra interfaces for flexibility. Should I say I missed deadline? Surely I did." Still not seeing it. "Professionals don’t write code, they solve business tasks" Ah, I see the problem. All of the above are examples of amateur programming. He's not talking about professional programming at all. Step 1: Go read The Psychology of Computer Programming, by Gerald Weinberg. From 19-fucking-73. Step 2: See Step 1. (Actually, that's not quite fair. Best-practice-itis wasn't a thing back then. But the fascination with doing things right rather than doing the right thing is really the other side of the same coin.)
• simonblack 5y ago
  Make it work, then make it good. Maybe I'm wrong, but that's what works for me. I don't get bogged down in arcane sideshows until much later, when it's an unimportant use of time. In the meantime, the software is working well and people can use it. AFTERTHOUGHT: I've always denigrated Microsoft for doing exactly that: "Microsoft doesn't get it right till Version 3". Seems I'm in 'good' company. <grin>