12 ms·

Software development is a loser’s game

132 points by lobo_tuerto 6y ago

AtNightWeCode 6y ago
One problem for me in Software development have been bosses, project managers, product owners, IT architects and so on. Sometimes they get too much power and are allowed to make decisions on how to write software. Bad code can be handled. How to handle software filled with bad ideas is more difficult.
at_a_remove 6y ago
This is one of those narrowly-focused articles that says it talks about a big topic ("software development") is about a much narrower portion of that topic. Most of my programs are for ETL, error-scanning, packaging up some manual tasks, and so on. I am in the long tail of dark matter developers. I do not have DevOps because it makes no sense to have DevOps where I am. I am solo, there's nobody else to code review with, and so I chug along like I have for the past forty years -- "yeah, that function looks like crap, I can fix that." There's a lot of people like me out there. We solve problems. We pick up a program we wrote ten years ago to make sure it is still usable before running it. We do not "deploy." I think we need some new vocabulary about the business of programming, because this narrow focus sounds like it ought to include the guy who makes a custom mortgage calculator for the local credit union in Visual Basic, but it really isn't about him or what he does, and it might not be bad to remember that he and I are out there, chugging away.
tomphoolery 6y ago
This article is so pompous. Calling people "amateurs" when they get paid to do something is hilarious at best and damaging to new developers at worst. It reeks of the "No True Scotsman" fallacy, by listing a set of good practices and then claiming that you're not a "true professional" unless you grok all of that. Get this Gen X snobby attitude out of software development. You're making it harder for the rest of us to hire developers we'd actually want to work with rather than snobby douchebags like yourself.
- helij 6y ago
  I'm Gen X and think the article is pompous as well. I don't get the feeling that my generation is pompous though.
- meiraleal 6y ago
  Amateur programmers can create profitable software, that's not the point of the article. An army is not made of elite soldiers. But it is important to discuss what is the foundation of being elite/pro in a field.
lmilcin 6y ago
> Amateur software developers dislike (...) I think that's wrong way to put it. I think the difference between pro and amateur might be, even if both dislike something, pro will understand he needs to do it properly anyway and why. For example, I dislike writing unit tests. In many years there has not been a single time the unit test saved me from anything. I tend to be very pedantic when writing code extremely careful when modifying code written by other people. I don't rely on tests to tell me I have messed something because I know these tests written by a person with lesser work ethics cannot be trusted. So before I modify anything I do thorough investigation to understand what I am modifying, what my modification can possibly cause and whether it is not a problem. If unit tests were done correctly (ie. up to the standard that would let me trust them) then yes, they would be helpful. But it requires only a single developer on the project, even one that has already departed, and you can no longer just trust tests to catch a problem. Also I am yet to see well tested code -- one that documents and thoroughly proves all detectable aspects of unit contract. So I understand I am paying the price for other people not making tests correctly but I still have to write them nonetheless. I hope you understand why I can BOTH dislike it and be professional about it, at the same time.
- Nursie 6y ago
  > In many years there has not been a single time the unit test saved me from anything. You've never even made a typo that a unit test has helped you spot? You've never, ever, had a unit test show you that one of the assumptions was wrong that you made about the behaviour of a piece of third party code? That seems mighty unusual to me...
  - lmilcin 6y ago
    As I said, I try to always thoroughly understand anything I am about to modify. For example, if I change a function body I always familiarize myself with how the function is being used, exactly, what the code of the function does, exactly and how other function it calls work, exactly.
    - aYsY4dDQ2NrcNzA 6y ago
zabzonk 6y ago
Lists some things that allegedly "amateurs" dislike without providing an ounce of evidence.
- joncp 6y ago
  Proving those points wasn't the goal of the article. His audience was people who already accept them.
  - watwut 6y ago
    Judging from HN discussion, his audience was offputted by article.
duxup 6y ago
This really seems to hinge on: >Why do I say this? >Amateur software developers dislike Is that a thing / the problem? I appreciate that laundry list can contribute to writing good code, but I kinda wonder how much that has to do with it vs ... just not writing good code, for some other reason (time, bad incentives). I've only been coding professionally for a handful of years, but I feel like I see a lot of reliance on various ideas and systems to produce good code. Programmers seem to think that they can enforce various systems and ideas to MAKE people write good code . While I think those can help, often I think those are used as all or nothing type measuring sticks. Personally I think an individual programmer's choices are more (or maybe less) complex than that, as are the outcomes, regardless of some laundry list.
ExcavateGrandMa 6y ago
reality is way worst than that... and until you get it... it's already too late... must live in ignorance, it seems easier to live :Ð
0d311 6y ago
500 error?
- kabdib 6y ago
  You're not missing much.
flatline 6y ago
This explains a lot of my interactions with my peers. Some groups of developers need hand holding, guidance, feedback, and correction. Continuously. The other group just gets stuff done and get normal feedback I”d expect from my own work. When one of the first group complains about code, I try to explain why it’s written that way. When the second group complains, I ask what we can do to fix it. Amateur vs pro may actually be a useful distinction here.
- varispeed 6y ago
  Sometimes this is a serious nightmare. Some younger developers think that pair programming is a given and that they expect that someone more senior will be developing with them, which often ends up you doing all the work because they don't understand even the basics. I know some people love it though, because they feel "better" and they have their little "being a teacher" fantasy going, but I try to leave such place as soon as possible.
  - flatline 6y ago
    It's definitely a nightmare if it's part of the culture. If it's a junior developer you are mentoring that's another story.
mpurham 6y ago
Definitely agree! Nowadays many developers skip over the design patterns, thinking abstractly, etc which over times causes technical debt. Many companies have very good processes in place and the above does not hold true for their employees. I was once at a company and was blown away with how well their code was structured, processes, etc I literally had no work to do (very rare).
varispeed 6y ago
One of the problems I faced is that the university didn't teach TDD, I couldn't find any books about TDD and every single programming course didn't even have a section about TDD. It's like this was some kind of secret knowledge that only few had. I was only able to learn TDD when I joined one corporation and it was like a new world to me. I tried to learn as much as I could and then carry that to next jobs. It's better now, but I feel like this knowledge is somehow still not shared as much. People still, when they create a course, they commit little time to testability and explaining how you can validate what they say. I find it frustrating then when new people come to work, they severely lack testing skills and that is not a fault of their own, just there is very little real world examples and tutorials. Some open source projects have good tests coverage so that's a great way to learn.
- Snoozle 6y ago
  On the flip side, as a dev with 10 years exp, I think TDD is a process crutch designed to cover up poor engineering by adding additional time spent to all work.
  - damau 6y ago
    Also the automated security scans. All new frameworks cover the cases. Real box ticking exercise. Though I am a TDD fan I understand your point.
    - swsieber 6y ago
      > Also the automated security scans Yes and no. At $WORK we started using a security scanner and I'm triaging the issues. It's definitely a box ticking thing. OTOH I'm finding real, concerning issues.
  - varispeed 6y ago
    There are people going for 100% coverage and pedantic unit testing so that it only works with that particular implementation they wrote and then when you want to change something, you'll have a pile of tests to change that don't add any value. Something like this we try to get rid of.
deleted 6y ago
[deleted]
preommr 6y ago
Because long-term maintenance isn't the concern. Most devs switch jobs in 2-5 years (or at least that's the common advice given). So the incentive is to play musical chairs, and hope that you've moved on by the time the music stops. Software has also been such a new field that it was the startup that moved fast and broke things that got the prize rather than the slow but stable company. I think this is changing (lower barrier to entry and ever-increasing complexity). But the momentum still exists.
- throwaway894345 6y ago
  Further, management notices and rewards the developer who is chewing through tickets, especially when those tickets are visible, user-facing features. If those developers are sloppy (and they tend to be), the bugs, readability issues, etc don’t get traced back to them and the rest of the team gets no glory for cleaning up after them and actually productionizing the prototype-grade shit they deploy to production.
  - MattGaiser 6y ago
    This happened to me in one of my first jobs. I chewed through tickets and regularly had an above average point score every sprint, even as a brand new junior developer. I sometimes had the highest on a team where everyone else had 5+ years of experience, which should have raised red flags. Heaps of praise though. And I was doing it by taking the most direct path to it working without really knowing the potential consequences (which I didn't understand at the time). The guy who wanted to do refactoring didn't get his contract renewed as that was not productive work.
    - emsy 6y ago
      Kudos to you for recognizing that. I know “senior” developers that wouldn’t see this effect from them or their team even if you told them. I know because I did, multiple times. It’s futile. Your best move is to leave in that situation.
- croo 6y ago
Fred27 6y ago
That article taught me more more about tennis than about software development.
- duxup 6y ago
  I wonder how it applies to most sports. I think the amateur strategy of "don't make as many mistakes" applies to professional team sports too. I can think of a lot of successful professional teams who for the most part simply outlast their opponent by not making mistakes and capitalizing on their opponents mistakes. American football for sure often has games turn on a handful of plays.
  - Toks 6y ago
    Any sort of competitive game or sport at a high level devolves into "don't make any mistake" whether it be chess, football or anything in-between.
- cableshaft 6y ago
  Also seems like it would apply to most competitive games. Like I can easily see the same concept applying to Chess. Looks like this is the Loser's Game essay he mentioned, btw. Also looks like in that essay, it's less about tennis and more about basically doing what the OP did, but applying the metaphor to investing: https://www.trendfollowing.com/whitepaper/the_losers_game.pdf https://www.trendfollowing.com/whitepaper/the_losers_game.pd...
  - zeptonaut22 6y ago
    I've found a lot of lessons can be drawn from competitive games with tight feedback loops and applied outside of those domains. There's something to be learned from these areas where there are a whole bunch of people trying very hard to get good at something (e.g. chess, Rocket League), especially with regards to how to build a mindset around failure and how to review your mistakes. The hard part in all of these is finding the right "hooks" in these pursuits that tend to be more obvious in competitive games. How do you "record your performance" when programming or holding meetings about business strategy? How do you review that recording after the fact? What criteria do you use to evaluate success and failure? It's certainly not as easy to do this with "games" that lack a clear scope like startups, but I've found regularly reviewing your performance ("Did this meeting have a clear agenda before starting?") and building checklists for what practices lead to success is immensely helpful.
onion2k 6y ago
For a long time I've wondered if it'd be a good idea to have my deploys look at the test coverage and refuse to deploy if it falls below a threshold. I think it's a good idea but I know it'd annoy the hell out of me if I actually implemented it..
- exactlysolved 6y ago
  I think error budgets are an excellent idea for this type of tension. Release crap that breaks too often? OK, you have taken too much of another team's resources, and will have to release less and/or check your work much more carefully. Release something that might look low quality to an outsider, but that actually works perfectly well? Fine - no negative consequences if nothing bad happens.
  - sidlls 6y ago
    This is fine when errors have clear boundaries or the system is more or less trivial. It's easy to have clearly defined error budgets and assignment of blame. In more complicated systems (e.g. mature companies or complex architectures) the assignment of blame becomes problematic, and that makes the tool (error budgets) less useful.
- varispeed 6y ago
  This removes so much headache in the long run. Often by writing tests you discover something not considered before and that improves the product a lot and its stability. I have some projects that have been online for like 4 years now without reboot. They have very good coverage. I hate going through logs and debugging, and I almost never do it after committing to testing. Things just work.
- psidium 6y ago
  Honestly it is hard going from no code-coverage to a rule of at least x% of code coverage. Instead of adding a blunt rule I went with something different: Some years ago I've implemented a check to fail the PRs if the lines touched on that PR don't have code coverage (delta-coverage = 100%). We aligned internally with all the affected developers and went with it. We defined that the rule is that 100% of the code needs to be covered, but it doesn't mean that the rules can't have case-by-case exceptions. Whenever someone needs an exception the teams gets together and approve an exception. Sometimes it is a backlog to write the tests later, or some files that don't need unit tests altogether. This may have worked for us because we are 5 years into this codebase and it keeps on growing, but for more small projects this may be more hassle than it is worth. Honestly, after the first 6 months (not easy, not gonna lie) I felt better about the codebase, and I love the confidence of trying things and having unit tests all around. There were times where I submitted a PR and forgot altogether to write tests and this rule caught me. I recommend it, but as with any software development practice, this is not a one-size-fits-all game.
xwolfi 6y ago
It looks like the kind of obvious linkedin article young people write after reading Clean Code :D I'd be more interested in project size, business pressure, cost incentives etc to explain why software always grow to a direction that seems to hinge on the unmanageable. For instance I agree and implement all he says, but let's take one example: we can love unit tests, and I never push something for review without many, but there are fundamental limits to them: you can assert wrong in many ways without any kind of measure beyond coverage, you can make the same mistakes in the tests as you did in the implementation because you just misunderstood the business, you can rush a solution to solve a problem happening yesterday, and test half of the problem etc. So doing unit tests ONLY won't save you either. My 2 cent would be to make us users of the software, that would really help move towards stuff we stuffer tenfold the limitations and failures of. Adding unit test in the process is the absolute minimum (so I agree amateurs only should dislike them), but still just the minimum to get anything serious out. The maximum is to make us the clients, or them the programmers. A direction we discuss in investment banking where we fire traders to replace them with people who can launch profilers during automated trading.
odipar 6y ago
Definition of a professional: "engaged in a specified activity as one's main paid occupation rather than as a pastime". I wouldn't call fixing azure pipelines without any professional debugging tools a pastime activity.
- obedm 6y ago
  I disliked the article because of that. Hinting that "amateurs" are working full time on programming jobs. Although I've met unprofessional people at work. Being a professional doesn't mean you're an expert.
MattGaiser 6y ago
Software developers are just responding to incentives. Managers/Product owners want features and aren't too bothered with defects, as the idea of bugs is so normal now. Do they care about defects? Yes, but only if the cost to fix them doesn't change the deadline.
- ryandrake 6y ago
  Nobody cares about a bug unless it's highly visible or dooms the product, and would rather you just cram feature after feature in. Nobody's ever been promoted for great work maintaining the old version, or for reducing our bug count by 50%. The result is a product that you cannot be proud of, because it's literally the worst thing that the customer will still buy.
- gkilmain 6y ago
  Yep, totally agree. Writing quality code is always on my mind but when something needs to be delivered yesterday what are you going to do? Options are: delay the release or release it with the crap we wrote
PragmaticPulp 6y ago
An ask of anyone reading this article: Please don’t let yourself become a smug or cynical programmer. Too many programmers read articles like this and assume that they are the 20% of good programmers while everyone who disagrees with them is the 80% of amateur developers: > I have worked in software development for 20 years, worked on many projects with many software developers. I estimate 80 percent of software developers are amateurs and 20 percent professionals Yes, it’s true that some programmers deliver better results than others. It’s also true that some have better methods than others. However, this is one of those situations where if you pulled developers aside and asked them to rank themselves relative to their peers, you might get 80% of people rating themselves as above average and 50% of people claiming to be in the top 20%. A common pitfall I see is when developers forget that the goal is to ship software and instead focus on doing everything the most correct and perfect way they can think of, regardless of their resources. I’ve worked with many teams of professional programmers who spent so much time perfecting their tooling and code and architecture that they rarely ever shipped anything. Learning the tools of the trade is important, but don’t lose sight of the goal: We need to strike a balance and get work done, not just perfect our craft in a vacuum.
- danybittel 6y ago
  And the people claiming to be in the top 20% are going to medium and post a blog post about it. I mean, he's not wrong.. but I always get suspicious if somebody is making up percentages. You know 90% of percentages are made up? (Yes I just made that up)
- monkpit 6y ago
  Yeah, I think it’s dangerous to try and say that there are 2 groups of people here. Instead, just say we are all amateurs and there’s no reason to take off the training wheels.
- bfgoodrich 6y ago
  These articles are intentionally written to satisfy that "I'm a better programmer" itch. Everyone imagines themselves to be the better programmer, and will always have a laundry list of reasons why they're just "better". And people will post it on twitter and LinkedIn, etc, under the rather pathetic guise that it will demonstrate they they are the professional. It's a cheap, tiring tactic.
damau 6y ago
Focusing on fixing bugs and maintainability can make a project substantially better long term. Though I am not very keen on the underlying reasons the author gives. Seem to be anecdotal and not cover a host of other situations the solution could cover. I think there can be many other reasons. Cultural for one. In the example of the professional team they may still be beholden to write cheap code because of certain business decisions, despite tests and the fanciest of ci builds. Additionally ‘amateur’ teams could still produce high functioning websites if there goals were shifted toward leaning and measurements taken against customer satisfaction and reduction of bugs over time.
christiansakai 6y ago
I have accepted the fact that writing tedious tests is part of life. It is better than having your code breaks somewhere.
terracatta 6y ago
> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line is packaged to sound really insightful, but is it? The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things. If I write no software today, I've also written no new bugs. But have I made any progress toward achieving the mission? Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility. It may be a necessary role at his organization, but I just don't agree with the cynical and depressing message.
- eithed 6y ago
  I understand where you're coming from, but I'd read it as writing code that will behave the way it's anticipated without any gotchas - merely writing code that works in a specific scenario shouldn't be the goal. Additional benefit would be to write code that easily extendable, but that's not mentioned here.
- eplanit 6y ago
  Did Deepak Chopra write the article? It's like "when you're nowhere you're 'now here'". It seems so clever... at first.
- protonimitate 6y ago
  Agreed - this article reads like a "get good" message to "amateurs". Which, sure, you should be striving for constant improvement - but if you work in an environment where sloppy/quick work is incentivized I would argue it's the responsibility of the "professional" to push back and set up an environment for success. Blaming all your issues on more junior members of the team is a huge red flag, and this article doesn't really offer any insight into how to bridge the gap between "amateur" and "professional" (which, imo, falls on the senior members of the team).
  - hoskinator 6y ago
quonn 6y ago
Experienced developers use their good judgement to apply the right amount of these kind of things where beneficial instead of blindly adhering to these rules.
rektide 6y ago
Big fan of Tom Gamon's Programming is a Losers Game (Sept 2020)[1]. Tom's short post was a very welcome introduction to the matter for me, very open ended, & Ben Hosking here elaborates much more clearly specific concerns & outlooks. [1] https://tomgamon.com/posts/a-losers-game/ https://tomgamon.com/posts/a-losers-game/ Both Ben in this "Software" and Tom Gamon in "Programming" anchor their arguments to Charles Ellis, & his example of tennis as a game where the talented score points, and amateurs inflict self harm. Both of these articles espouse a similar, conservative minded viewpoint that maintaining & supporting is a more key or perhaps just more-absent activity than progressing. They warn that devotion to progressing/going out and winning often brings about doom & trouble. They speak to us of the hazards about, that the paths available to the software's future becomes confined or the ground unsteady if we don't take our software environment seriously. I'm both very sympathetic to this software-conservatism , because (a) legacy systems/the past rule so much of the software world, and (b) we certainly do make confounded mistakes a lot, but also deeply worried about what it's done to our moral character. Software isn't eating the world anymore: it's past that now, that's past tense. Software has eaten the world. At almost everyone company you go to your world will almost entirely be already consumed by mounds of existing software, upon which the company is most often busy accreting new layers of software that will shortly settle into place & likewise become buried. It's a frank truth that minding your environment, trying to insure some safety & quality to the layers is critical, the belief that we should/ought/must build solid baseis extremely valuable here. But I somewhat fret programmers have been tamed into minding our own loser-dom, am concerned that we stop looking up to the stars, when we stop being brazenly brave. We have immense immense powers, and from so many camps- within the programmerhood & external- I see a reaction of panic, & fear, & distrust to potential. Which is both warranted, but also really quite besides the point, is too often too strong a diminishing force for great potentials programmers have such keen great sense for. I feel there is an over-regulation, an over-pressuing on our social systems these days. "Overnight Pizza and the Consistent Unreliability of Expert Guidelines"[2][3] is recent article ostensibly about Expert Opinions & the low-information-density environments such guidelines are crafted in & for, but it's also an incredible story about social pressure, the urge to be right, about the emotional high one gets from being certainly completely correct & proper & everyone else being a fool. It's about overly absolutist perspectives, that don't allow for a bigger continuum of opinions. And I think a lot of software folk have turned in to the "overnight pizza will kill you" camp: they have encountered some parts of the maelstrom, tasted what the uncivilized is like, and their reaction is to build & fortify against the encroaching dark, to turtle up, & build strong best practices & robust processes. Which is both noble, respectable, given the maelstrom of software, but also... I feel like our lack of adventurous spirit often holds us to petty tasks, and keeps us from exploring & seeking better lands, with much richer yields. [2] https://residentcontrarian.substack.com/p/overnight-pizza-and-the-consistent https://residentcontrarian.substack.com/p/overnight-pizza-an... [3] https://news.ycombinator.com/item?id=26635856 https://news.ycombinator.com/item?id=26635856 Programmers, the New Kingmakers[4], are also in an enormous tension. Business's often proclaim that they want go-getter attitude, that they folks focused on landing wins, making sure their every effort helps the customer. But often programmers are very very alone in seeing a bigger picture, seeing long term costs, seeing how the business is creating amateur grade software that will not hold up. Programmers can feel under strain to deliver, and conservatism naturally results, a concern that things will fall apart, that core formative activities won't have time to occur or mature, that the result will be disorder. Few companies internalize & earnestly grapple with an understanding of how the sausage is made, programmers often view other people as viewing them as resources, to be used, tapped, often without awareness or responsible handling, without understanding that the magic has a price, that it's stacking up. Those closest to the craft have a deeper insight into how the business's "win orientation" is creating (& compounding) amateur losses, and they feel enormous protectivity: that they must claw from the business the good acts it cannot see and that it needs. [4] https://thenewkingmakers.com/ https://thenewkingmakers.com/ But that's not the worst part of the business environment to me. The worst to me is writ large in "Why software engineers should be CEOs"[5]. We are incredibly creative, we see enormous potential at every step. Only rarely does the business let us drive towards the true fantastic excellences that we dream of pursuing. Just as the business doesn't understand the loser's game challenges that are all over the place, oh, sad, the business also does not have anywhere near the vision or creativity of the individual, of the coder, who sees possibility & value oozing out of so many areas, often so untapped. And programmers are not put into decision making roles nearly enough, not given structure & the attitude that they can strike, that they can chase down big game, game the rest of the company often has a hard time seeing. The socialization processes that work places must go through to allow commitment are very high, and so programmers simply do not have the time, ability, or often even the common language to get the businesses play the winning game. We must trust that the business somehow is aligned to let us make them kings, rather than taking an active stake in pushing the business towards their would be kingdomship. [5] https://www.tlt21.com/why-software-engineers-should-become-ceos/ https://www.tlt21.com/why-software-engineers-should-become-c... Beware committing your life to mastering the losers game!! You are the dreamer of dreams. It hurts, it's always a challenge, but please, dear fellow programmer, stay in touch with your noble (& a little bit wilder) selves. I believe in you.
havkom 6y ago
The ”game” of software development is rather ”won” by understanding the surrounding business and delivering on those goals rather than any, by software developers made up, “goals” about “standards”, “unit testing” or “SOLID design patterns”. The game is also about good co-operation, helping colleagues succeed without imposing dogmatic requirements, and making friends with influential people connected to the software development team. This is rather an article about loosing the “game”.
- emsy 6y ago
  Dogmatic rules are for people that don’t know yet when to break the rules. Ironically, a lot of lead engineers I worked with don’t know that this is what dogmatic rules are for so they impose them to appear competent.
uberswe 6y ago
The author makes a list of things a “professional” developer uses. Among these are SOLID principles and design patterns. While they are good things to understand, I have met many developers who follow such principles without thinking and try to apply them to every task. This can make something really simple very complex when it doesn’t need to be.
abledon 6y ago
>80 percent of software developers are amateurs and 20 percent professionals. Why do I say this? >Amateur software developers dislike - Standards - Unit testing - Design patterns/SOLID principles - Learning and setting DevOps and ALM (They like using it) - Fixing the build - Code reviews - Code Analysis/Solution checking What a troll statement, no way do 80% of software developers dislike those things.. maybe.. 20%?
- foobarian 6y ago
  Let's not even get into definitions of amateur and professional. Working with this guy? Hard pass.
- alexjplant 6y ago
  I've had the misfortune of working at a few places were many/most of these things were pretty universally frowned upon. > - Standards Resistance to using formatters and linters because they prevent you from merging code more quickly; "it's annoying". Two of the two-dozen devs on the product decide that they want to use NetBeans instead of Eclipse even though the formatter is built for the the latter and everybody else uses it so they can't format their code properly. > - Unit testing I recently went four years without writing a single unit test professionally. When I _did_ write unit tests I worked on one team where the only important metric was coverage percentage, not corner/edge cases or intentionally trying to break the software. People would write tests for auto-generated getters and setters in C#. That's right - they would _test the compiler_ just to satisfy a business metric. > - Design patterns/SOLID principles My tech lead at a previous job refactored a pretty substantial service I wrote with no team input to remove any semblance of organization or convention. The repositories, factories, and facades I built got merged into a giant single "helper" object just to follow some weird anti-pattern that they'd established. It wasn't testable, there was no separation of concerns, and it ended up being nigh-unreadable. > - Learning and setting DevOps and ALM (They like using it) > - Fixing the build I've been the "CI guy" at almost every software job I've had because some people are afraid of the command line and lack an understanding of the build tooling outside of the three SCM operations they know through Tortoise and the play button in their IDE. I could go on but you get my point. Software development is a vast industry and there are some pretty dark corners. For every high-performing team that has tech-savvy devs there are body shops full of people that are trained by rote to "build software". It's not pretty.
crazypython 6y ago
> Unit testing In the game development, videogames are primarily tested by humans. Games are highly interactive pieces of software often running on a variety of hardware with complex agent-based simulations. Are all game developers "amateurs"? I don't think so.
- _3u10 6y ago
  Yeah, I couldn’t find the dev ops folder or the unit test folder in the Linux kernel sources either. Any idea on how they get the kernel to scale without kubernetes?
- watwut 6y ago
  Videogames overall are primary tested by humans, but smaller components inside them do have unit tests. Unit test and integration testing are two different things.
  - crazypython 6y ago
    Hmmmm, how would you test, for instance, a rendering engine?
    - watwut 6y ago
      Majority of it are pure calculations that are easy to test automatically. Was this even serious question?
renewiltord 6y ago
Nothing particularly unique about the software part. But the quoted text is interesting: that is kind of true about pro vs amateur tennis (or table tennis or badminton). Didn't quite notice it. Still, amateur tennis is funner when you play to win the point :D
agentultra 6y ago
I too have been in software development for 20+ years. The most effective thing we can do to write better software is to get good rest, reduce stress in the work place, and learn to write and communicate effectively. After that comes skills with the tools and processes around writing software: technical, mechanical skills that can be taught and managed. You need a mix of people from different skill levels to make an effective team. "Amateur," or "junior," or whatever you classify folks with less experience as bring a lot of energy and enthusiasm to a project. They're often eager to learn and many don't know what isn't possible yet and bring fresh ideas to the table (not every idea is a good one but it's nice having folks on your team who are keeping everyone out of a rut). On the opposite end I don't think you can have "senior" or "professional" developers without anyone to mentor or train and work with. In order to solidify your understanding of a topic you have to be able to communicate it to an audience with less specialization and understanding than you. Knowledge takes time to develop into facts we can take for granted. Update: If you're interested in empirical evidence of the effectiveness of various software development practices, a handy, light resource: https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ tldr; very few practices we eschew as a professional obligation, like being diligent about writing unit tests, have little evidence to support their effectiveness in reducing errors. The things that do work: sleep, low stress, writing, and probably code review.
dasil003 6y ago
Interesting idea, but doesn’t really hold up because software development is not adversarial. Now security on the other hand...
parasubvert 6y ago
I’ve seen plenty of “amateurs” write unit tests, CI/CD, adhere to standards, pair program or deal with code reviews, etc. Inevitably this has 100% to do with the culture of the work environment. Either those things are mandatory, enforced by both peers and management, or they’re optional. This reads like a rant about a low discipline organization, where it’s impossible to change the culture, and thus easier to crap on those who don’t know any better.
ambientlight 6y ago
Title could have been less clickbaity
_3u10 6y ago
If you’re tired of software dev try http://programming-motherfucker.com/ http://programming-motherfucker.com/ instead.
zwieback 6y ago
To be fair, a lot of traditional science and engineering follows the same pattern. I'm a SW dev embedded in an R&D engineering organization and the main difference is that SW development has faster cycles and less established practices but if you scale up SW dev timelines to match ME and EE cycles it's not that different. Preventing bugs is something especially our materials and system interaction engineers are very aware of. You don't want a consumer product to fail in the field and cause damage or harm so that's goal #1.
ChrisArchitect 6y ago
more previous discussion from a few days ago: https://news.ycombinator.com/item?id=26630731 https://news.ycombinator.com/item?id=26630731
avelis 6y ago
The title is a little clickbaity. In my engineering management experience I instill the following values to decent success. * Write tests for almost all code. * Code review with peers. * Deploy frequently with roll-backs. * Reward each other when things go well. * Help each other when things go wrong. This leads to high test coverage, good knowledge sharing, progressional changes, and a healthy work culture.
pinkybanana 6y ago
I was at a startup, we almost never wrote tests, just hacked like amateurs in the way this guy seems to despite. But we managed to sell the startup and got rich. Now the software we hacked together is being maintained by professional programmers. They have tests and all those fancy processes and what not. They get paid nice salary but they'll probably never get rich like the founder programmers. I'm pretty sure also we wouldn't got rich with writing the unit tests and what not. We just needed to implement it quickly and provide good enough version. To me the writer sounds more like loser than the amateurs he mocks. But I guess it is on whatever side of the fence you are. Nothing wrong preferring one or another.
- meiraleal 6y ago
  Perfect. Although I agree with the writer, context is everything. It is like static vs dynamic typed languages. If typed was really better for every case, dynamic wouldn't be as big (or bigger).
TheCapn 6y ago
Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. Whoever had written this project before me wrote no tests, and basically brute forced features to work. A dropdown box that loaded options dynamically based on other user selections had 18 variables buried in the code where 8 of them were either unused or redundant. For a fucking dropdown box? I told the PM 1 week in that I'm not going to make the delivery deadline and he should be advising the client of such. --- I don't want to talk bad of my coworkers so I'll just say this. I'm the only developer in my company with a software background. Everyone else is electrical engineering/tech and it shows when you review their code. Comparing this "Amateur" vs. "Professional" article to what I am currently going through feels almost cathartic knowing this is something widely experienced in the field. I truly love my job, but some days, like these last days, really make me want to unplug from the world and go live in the wild because not only do Amateurs make these mistakes, they're also blind to the Professional ways of approaching work. It almost felt like an argument at times convincing him that this "extra" work that was neglected previously is necessary and should be factored into everyone's projects, not just mine.
- danans 6y ago
  > What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.
  - hnarn 6y ago
    If you ask someone to give you an estimate for work needing to be done on your car, not only is it obvious that they will have to look at the car first, it's also obvious that the estimated cost and/or time may and often will overrun (although you're normally notified and asked before it does). It seems like both of these things should be equally obvious in software.
cperkins 6y ago
I think the "winners game" vs. "losers game" insight is interesting and there is some value in applying it to software development. But I don't see it as a revolutionary insight, anything that's going to radically change anyones understanding. The article has other problems, but overall it's just lukewarm. To my mind, the main issues in software development are complexity and imperfect knowledge. We've developed a lot of practices like unit tests and code reviews which help us defend ourselves, but, ultimately, for any non-trivial software it seems like a losing battle, or if not losing, then the progress is slow and difficult and tenuous. (like trench warfare).
renox 6y ago
In theory, that's true, unfortunately often "professionals" write poor code like amateurs and then spend all their time in debugging :-(
austincheney 6y ago
> Amateur software developers dislike While the rest of the list is valid the author could have stopped at the first item Standards and still have made his point. Perhaps the most perfect example of that is why JSON won versus XML for data serialization. Many people will claim that it's because XML is bloated. After all this was the primary argument of JSON's inventor Douglas Crockford. They aren't wrong, but its not why JSON won. JSON won because it's specification is tiny. When all the boilerplate is scrapped off the latest version is about 5 tiny pages of text any high school student can understand: https://tools.ietf.org/html/rfc8259 https://tools.ietf.org/html/rfc8259 Compare that to XML: * XML - https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ * XML Schema - https://www.w3.org/TR/xmlschema11-1/ https://www.w3.org/TR/xmlschema11-1/ * XSL - https://www.w3.org/TR/xsl11/ https://www.w3.org/TR/xsl11/ Those are HUGE and they are written to conformance precision for implementation engineers. No high school student will ever read any of that for pleasure. I remember reading those when I first entered software development and absolutely everybody thought I was out of my mind and promptly discarded everything I said if they didn't already know it. I remember that being particularly frustrating because ever recommendation or proposal had to read like a pitch deck to a VC, but if I wanted to do that instead of engineering or product development I would be brand evangelism or merchandising. XML for a data conveyance medium is extremely powerful, but in practice this is completely irrelevant. XML is a world unto itself in all of its capabilities and potential, but that doesn't matter if nobody is using it. Most Americans, regardless of their actual educational attainment read at a 9th grade level (high school freshman). That applies to entry level software developers as well. Computer scientists and inventors are not the average of software developers. On one hand this is great, because I truly believe anybody can be a software developer and write really bad code. On the other hand this is horrible, because many people are code monkeys that write either bad code only or are fundamentally limited to a small subset of solutions limited by a small subset of tools.
deleted 6y ago
[deleted]
karmakaze 6y ago
A vapid post that doesn't cover a vast range of 'winning' development strategies that aren't about 'not losing'. Direct things like really understanding the problem you're trying to solve; Making invalid states unrepresentable; Using composable techniques to separate parts of a problem that can be combined safely and meaningfully.
bokohut 6y ago
My first exposure to computers and writing code was on an Apple in the mid 1980s, I was hooked at a very young age. Since that time I have obtained a higher education degree in software development as well as architected, coded and managed entire enterprise platforms for multiple businesses I have founded. As an entrepreneurial software development loser I stand proud and sm:)e.

132 points by lobo_tuerto 6y ago

One problem for me in Software development have been bosses, project managers, product owners, IT architects and so on. Sometimes they get too much power and are allowed to make decisions on how to write software. Bad code can be handled. How to handle software filled with bad ideas is more difficult.

at_a_remove 6y ago

This is one of those narrowly-focused articles that says it talks about a big topic ("software development") is about a much narrower portion of that topic. Most of my programs are for ETL, error-scanning, packaging up some manual tasks, and so on. I am in the long tail of dark matter developers. I do not have DevOps because it makes no sense to have DevOps where I am. I am solo, there's nobody else to code review with, and so I chug along like I have for the past forty years -- "yeah, that function looks like crap, I can fix that." There's a lot of people like me out there. We solve problems. We pick up a program we wrote ten years ago to make sure it is still usable before running it. We do not "deploy." I think we need some new vocabulary about the business of programming, because this narrow focus sounds like it ought to include the guy who makes a custom mortgage calculator for the local credit union in Visual Basic, but it really isn't about him or what he does, and it might not be bad to remember that he and I are out there, chugging away.

tomphoolery 6y ago

This article is so pompous. Calling people "amateurs" when they get paid to do something is hilarious at best and damaging to new developers at worst. It reeks of the "No True Scotsman" fallacy, by listing a set of good practices and then claiming that you're not a "true professional" unless you grok all of that. Get this Gen X snobby attitude out of software development. You're making it harder for the rest of us to hire developers we'd actually want to work with rather than snobby douchebags like yourself.

helij 6y ago
I'm Gen X and think the article is pompous as well. I don't get the feeling that my generation is pompous though.
meiraleal 6y ago
Amateur programmers can create profitable software, that's not the point of the article. An army is not made of elite soldiers. But it is important to discuss what is the foundation of being elite/pro in a field.

lmilcin 6y ago

> Amateur software developers dislike (...) I think that's wrong way to put it. I think the difference between pro and amateur might be, even if both dislike something, pro will understand he needs to do it properly anyway and why. For example, I dislike writing unit tests. In many years there has not been a single time the unit test saved me from anything. I tend to be very pedantic when writing code extremely careful when modifying code written by other people. I don't rely on tests to tell me I have messed something because I know these tests written by a person with lesser work ethics cannot be trusted. So before I modify anything I do thorough investigation to understand what I am modifying, what my modification can possibly cause and whether it is not a problem. If unit tests were done correctly (ie. up to the standard that would let me trust them) then yes, they would be helpful. But it requires only a single developer on the project, even one that has already departed, and you can no longer just trust tests to catch a problem. Also I am yet to see well tested code -- one that documents and thoroughly proves all detectable aspects of unit contract. So I understand I am paying the price for other people not making tests correctly but I still have to write them nonetheless. I hope you understand why I can BOTH dislike it and be professional about it, at the same time.

Nursie 6y ago
> In many years there has not been a single time the unit test saved me from anything. You've never even made a typo that a unit test has helped you spot? You've never, ever, had a unit test show you that one of the assumptions was wrong that you made about the behaviour of a piece of third party code? That seems mighty unusual to me...
- lmilcin 6y ago
  As I said, I try to always thoroughly understand anything I am about to modify. For example, if I change a function body I always familiarize myself with how the function is being used, exactly, what the code of the function does, exactly and how other function it calls work, exactly.
  - aYsY4dDQ2NrcNzA 6y ago

zabzonk 6y ago

Lists some things that allegedly "amateurs" dislike without providing an ounce of evidence.

joncp 6y ago
Proving those points wasn't the goal of the article. His audience was people who already accept them.
- watwut 6y ago
  Judging from HN discussion, his audience was offputted by article.

duxup 6y ago

This really seems to hinge on: >Why do I say this? >Amateur software developers dislike Is that a thing / the problem? I appreciate that laundry list can contribute to writing good code, but I kinda wonder how much that has to do with it vs ... just not writing good code, for some other reason (time, bad incentives). I've only been coding professionally for a handful of years, but I feel like I see a lot of reliance on various ideas and systems to produce good code. Programmers seem to think that they can enforce various systems and ideas to MAKE people write good code . While I think those can help, often I think those are used as all or nothing type measuring sticks. Personally I think an individual programmer's choices are more (or maybe less) complex than that, as are the outcomes, regardless of some laundry list.

ExcavateGrandMa 6y ago

reality is way worst than that... and until you get it... it's already too late... must live in ignorance, it seems easier to live :Ð

0d311 6y ago

500 error?

kabdib 6y ago
You're not missing much.

flatline 6y ago

This explains a lot of my interactions with my peers. Some groups of developers need hand holding, guidance, feedback, and correction. Continuously. The other group just gets stuff done and get normal feedback I”d expect from my own work. When one of the first group complains about code, I try to explain why it’s written that way. When the second group complains, I ask what we can do to fix it. Amateur vs pro may actually be a useful distinction here.

varispeed 6y ago
Sometimes this is a serious nightmare. Some younger developers think that pair programming is a given and that they expect that someone more senior will be developing with them, which often ends up you doing all the work because they don't understand even the basics. I know some people love it though, because they feel "better" and they have their little "being a teacher" fantasy going, but I try to leave such place as soon as possible.
- flatline 6y ago
  It's definitely a nightmare if it's part of the culture. If it's a junior developer you are mentoring that's another story.

mpurham 6y ago

Definitely agree! Nowadays many developers skip over the design patterns, thinking abstractly, etc which over times causes technical debt. Many companies have very good processes in place and the above does not hold true for their employees. I was once at a company and was blown away with how well their code was structured, processes, etc I literally had no work to do (very rare).

varispeed 6y ago

One of the problems I faced is that the university didn't teach TDD, I couldn't find any books about TDD and every single programming course didn't even have a section about TDD. It's like this was some kind of secret knowledge that only few had. I was only able to learn TDD when I joined one corporation and it was like a new world to me. I tried to learn as much as I could and then carry that to next jobs. It's better now, but I feel like this knowledge is somehow still not shared as much. People still, when they create a course, they commit little time to testability and explaining how you can validate what they say. I find it frustrating then when new people come to work, they severely lack testing skills and that is not a fault of their own, just there is very little real world examples and tutorials. Some open source projects have good tests coverage so that's a great way to learn.

Snoozle 6y ago
On the flip side, as a dev with 10 years exp, I think TDD is a process crutch designed to cover up poor engineering by adding additional time spent to all work.
- damau 6y ago
  Also the automated security scans. All new frameworks cover the cases. Real box ticking exercise. Though I am a TDD fan I understand your point.
  - swsieber 6y ago
    > Also the automated security scans Yes and no. At $WORK we started using a security scanner and I'm triaging the issues. It's definitely a box ticking thing. OTOH I'm finding real, concerning issues.
- varispeed 6y ago
  There are people going for 100% coverage and pedantic unit testing so that it only works with that particular implementation they wrote and then when you want to change something, you'll have a pile of tests to change that don't add any value. Something like this we try to get rid of.

deleted 6y ago

[deleted]

preommr 6y ago

Because long-term maintenance isn't the concern. Most devs switch jobs in 2-5 years (or at least that's the common advice given). So the incentive is to play musical chairs, and hope that you've moved on by the time the music stops. Software has also been such a new field that it was the startup that moved fast and broke things that got the prize rather than the slow but stable company. I think this is changing (lower barrier to entry and ever-increasing complexity). But the momentum still exists.

throwaway894345 6y ago
Further, management notices and rewards the developer who is chewing through tickets, especially when those tickets are visible, user-facing features. If those developers are sloppy (and they tend to be), the bugs, readability issues, etc don’t get traced back to them and the rest of the team gets no glory for cleaning up after them and actually productionizing the prototype-grade shit they deploy to production.
- MattGaiser 6y ago
  This happened to me in one of my first jobs. I chewed through tickets and regularly had an above average point score every sprint, even as a brand new junior developer. I sometimes had the highest on a team where everyone else had 5+ years of experience, which should have raised red flags. Heaps of praise though. And I was doing it by taking the most direct path to it working without really knowing the potential consequences (which I didn't understand at the time). The guy who wanted to do refactoring didn't get his contract renewed as that was not productive work.
  - emsy 6y ago
    Kudos to you for recognizing that. I know “senior” developers that wouldn’t see this effect from them or their team even if you told them. I know because I did, multiple times. It’s futile. Your best move is to leave in that situation.
croo 6y ago

Fred27 6y ago

That article taught me more more about tennis than about software development.

duxup 6y ago
I wonder how it applies to most sports. I think the amateur strategy of "don't make as many mistakes" applies to professional team sports too. I can think of a lot of successful professional teams who for the most part simply outlast their opponent by not making mistakes and capitalizing on their opponents mistakes. American football for sure often has games turn on a handful of plays.
- Toks 6y ago
  Any sort of competitive game or sport at a high level devolves into "don't make any mistake" whether it be chess, football or anything in-between.
cableshaft 6y ago
Also seems like it would apply to most competitive games. Like I can easily see the same concept applying to Chess. Looks like this is the Loser's Game essay he mentioned, btw. Also looks like in that essay, it's less about tennis and more about basically doing what the OP did, but applying the metaphor to investing: https://www.trendfollowing.com/whitepaper/the_losers_game.pdf https://www.trendfollowing.com/whitepaper/the_losers_game.pd...
- zeptonaut22 6y ago
  I've found a lot of lessons can be drawn from competitive games with tight feedback loops and applied outside of those domains. There's something to be learned from these areas where there are a whole bunch of people trying very hard to get good at something (e.g. chess, Rocket League), especially with regards to how to build a mindset around failure and how to review your mistakes. The hard part in all of these is finding the right "hooks" in these pursuits that tend to be more obvious in competitive games. How do you "record your performance" when programming or holding meetings about business strategy? How do you review that recording after the fact? What criteria do you use to evaluate success and failure? It's certainly not as easy to do this with "games" that lack a clear scope like startups, but I've found regularly reviewing your performance ("Did this meeting have a clear agenda before starting?") and building checklists for what practices lead to success is immensely helpful.

onion2k 6y ago

For a long time I've wondered if it'd be a good idea to have my deploys look at the test coverage and refuse to deploy if it falls below a threshold. I think it's a good idea but I know it'd annoy the hell out of me if I actually implemented it..

exactlysolved 6y ago
I think error budgets are an excellent idea for this type of tension. Release crap that breaks too often? OK, you have taken too much of another team's resources, and will have to release less and/or check your work much more carefully. Release something that might look low quality to an outsider, but that actually works perfectly well? Fine - no negative consequences if nothing bad happens.
- sidlls 6y ago
  This is fine when errors have clear boundaries or the system is more or less trivial. It's easy to have clearly defined error budgets and assignment of blame. In more complicated systems (e.g. mature companies or complex architectures) the assignment of blame becomes problematic, and that makes the tool (error budgets) less useful.
varispeed 6y ago
This removes so much headache in the long run. Often by writing tests you discover something not considered before and that improves the product a lot and its stability. I have some projects that have been online for like 4 years now without reboot. They have very good coverage. I hate going through logs and debugging, and I almost never do it after committing to testing. Things just work.
psidium 6y ago
Honestly it is hard going from no code-coverage to a rule of at least x% of code coverage. Instead of adding a blunt rule I went with something different: Some years ago I've implemented a check to fail the PRs if the lines touched on that PR don't have code coverage (delta-coverage = 100%). We aligned internally with all the affected developers and went with it. We defined that the rule is that 100% of the code needs to be covered, but it doesn't mean that the rules can't have case-by-case exceptions. Whenever someone needs an exception the teams gets together and approve an exception. Sometimes it is a backlog to write the tests later, or some files that don't need unit tests altogether. This may have worked for us because we are 5 years into this codebase and it keeps on growing, but for more small projects this may be more hassle than it is worth. Honestly, after the first 6 months (not easy, not gonna lie) I felt better about the codebase, and I love the confidence of trying things and having unit tests all around. There were times where I submitted a PR and forgot altogether to write tests and this rule caught me. I recommend it, but as with any software development practice, this is not a one-size-fits-all game.

xwolfi 6y ago

It looks like the kind of obvious linkedin article young people write after reading Clean Code :D I'd be more interested in project size, business pressure, cost incentives etc to explain why software always grow to a direction that seems to hinge on the unmanageable. For instance I agree and implement all he says, but let's take one example: we can love unit tests, and I never push something for review without many, but there are fundamental limits to them: you can assert wrong in many ways without any kind of measure beyond coverage, you can make the same mistakes in the tests as you did in the implementation because you just misunderstood the business, you can rush a solution to solve a problem happening yesterday, and test half of the problem etc. So doing unit tests ONLY won't save you either. My 2 cent would be to make us users of the software, that would really help move towards stuff we stuffer tenfold the limitations and failures of. Adding unit test in the process is the absolute minimum (so I agree amateurs only should dislike them), but still just the minimum to get anything serious out. The maximum is to make us the clients, or them the programmers. A direction we discuss in investment banking where we fire traders to replace them with people who can launch profilers during automated trading.

odipar 6y ago

Definition of a professional: "engaged in a specified activity as one's main paid occupation rather than as a pastime". I wouldn't call fixing azure pipelines without any professional debugging tools a pastime activity.

obedm 6y ago
I disliked the article because of that. Hinting that "amateurs" are working full time on programming jobs. Although I've met unprofessional people at work. Being a professional doesn't mean you're an expert.

MattGaiser 6y ago

Software developers are just responding to incentives. Managers/Product owners want features and aren't too bothered with defects, as the idea of bugs is so normal now. Do they care about defects? Yes, but only if the cost to fix them doesn't change the deadline.

ryandrake 6y ago
Nobody cares about a bug unless it's highly visible or dooms the product, and would rather you just cram feature after feature in. Nobody's ever been promoted for great work maintaining the old version, or for reducing our bug count by 50%. The result is a product that you cannot be proud of, because it's literally the worst thing that the customer will still buy.
gkilmain 6y ago
Yep, totally agree. Writing quality code is always on my mind but when something needs to be delivered yesterday what are you going to do? Options are: delay the release or release it with the crap we wrote

PragmaticPulp 6y ago

An ask of anyone reading this article: Please don’t let yourself become a smug or cynical programmer. Too many programmers read articles like this and assume that they are the 20% of good programmers while everyone who disagrees with them is the 80% of amateur developers: > I have worked in software development for 20 years, worked on many projects with many software developers. I estimate 80 percent of software developers are amateurs and 20 percent professionals Yes, it’s true that some programmers deliver better results than others. It’s also true that some have better methods than others. However, this is one of those situations where if you pulled developers aside and asked them to rank themselves relative to their peers, you might get 80% of people rating themselves as above average and 50% of people claiming to be in the top 20%. A common pitfall I see is when developers forget that the goal is to ship software and instead focus on doing everything the most correct and perfect way they can think of, regardless of their resources. I’ve worked with many teams of professional programmers who spent so much time perfecting their tooling and code and architecture that they rarely ever shipped anything. Learning the tools of the trade is important, but don’t lose sight of the goal: We need to strike a balance and get work done, not just perfect our craft in a vacuum.

danybittel 6y ago
And the people claiming to be in the top 20% are going to medium and post a blog post about it. I mean, he's not wrong.. but I always get suspicious if somebody is making up percentages. You know 90% of percentages are made up? (Yes I just made that up)
monkpit 6y ago
Yeah, I think it’s dangerous to try and say that there are 2 groups of people here. Instead, just say we are all amateurs and there’s no reason to take off the training wheels.
bfgoodrich 6y ago
These articles are intentionally written to satisfy that "I'm a better programmer" itch. Everyone imagines themselves to be the better programmer, and will always have a laundry list of reasons why they're just "better". And people will post it on twitter and LinkedIn, etc, under the rather pathetic guise that it will demonstrate they they are the professional. It's a cheap, tiring tactic.

damau 6y ago

Focusing on fixing bugs and maintainability can make a project substantially better long term. Though I am not very keen on the underlying reasons the author gives. Seem to be anecdotal and not cover a host of other situations the solution could cover. I think there can be many other reasons. Cultural for one. In the example of the professional team they may still be beholden to write cheap code because of certain business decisions, despite tests and the fanciest of ci builds. Additionally ‘amateur’ teams could still produce high functioning websites if there goals were shifted toward leaning and measurements taken against customer satisfaction and reduction of bugs over time.

christiansakai 6y ago

I have accepted the fact that writing tedious tests is part of life. It is better than having your code breaks somewhere.

terracatta 6y ago

> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line is packaged to sound really insightful, but is it? The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things. If I write no software today, I've also written no new bugs. But have I made any progress toward achieving the mission? Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility. It may be a necessary role at his organization, but I just don't agree with the cynical and depressing message.

eithed 6y ago
I understand where you're coming from, but I'd read it as writing code that will behave the way it's anticipated without any gotchas - merely writing code that works in a specific scenario shouldn't be the goal. Additional benefit would be to write code that easily extendable, but that's not mentioned here.
eplanit 6y ago
Did Deepak Chopra write the article? It's like "when you're nowhere you're 'now here'". It seems so clever... at first.
protonimitate 6y ago
Agreed - this article reads like a "get good" message to "amateurs". Which, sure, you should be striving for constant improvement - but if you work in an environment where sloppy/quick work is incentivized I would argue it's the responsibility of the "professional" to push back and set up an environment for success. Blaming all your issues on more junior members of the team is a huge red flag, and this article doesn't really offer any insight into how to bridge the gap between "amateur" and "professional" (which, imo, falls on the senior members of the team).
- hoskinator 6y ago

quonn 6y ago

Experienced developers use their good judgement to apply the right amount of these kind of things where beneficial instead of blindly adhering to these rules.

rektide 6y ago

Big fan of Tom Gamon's Programming is a Losers Game (Sept 2020)[1]. Tom's short post was a very welcome introduction to the matter for me, very open ended, & Ben Hosking here elaborates much more clearly specific concerns & outlooks. [1] https://tomgamon.com/posts/a-losers-game/ https://tomgamon.com/posts/a-losers-game/ Both Ben in this "Software" and Tom Gamon in "Programming" anchor their arguments to Charles Ellis, & his example of tennis as a game where the talented score points, and amateurs inflict self harm. Both of these articles espouse a similar, conservative minded viewpoint that maintaining & supporting is a more key or perhaps just more-absent activity than progressing. They warn that devotion to progressing/going out and winning often brings about doom & trouble. They speak to us of the hazards about, that the paths available to the software's future becomes confined or the ground unsteady if we don't take our software environment seriously. I'm both very sympathetic to this software-conservatism , because (a) legacy systems/the past rule so much of the software world, and (b) we certainly do make confounded mistakes a lot, but also deeply worried about what it's done to our moral character. Software isn't eating the world anymore: it's past that now, that's past tense. Software has eaten the world. At almost everyone company you go to your world will almost entirely be already consumed by mounds of existing software, upon which the company is most often busy accreting new layers of software that will shortly settle into place & likewise become buried. It's a frank truth that minding your environment, trying to insure some safety & quality to the layers is critical, the belief that we should/ought/must build solid baseis extremely valuable here. But I somewhat fret programmers have been tamed into minding our own loser-dom, am concerned that we stop looking up to the stars, when we stop being brazenly brave. We have immense immense powers, and from so many camps- within the programmerhood & external- I see a reaction of panic, & fear, & distrust to potential. Which is both warranted, but also really quite besides the point, is too often too strong a diminishing force for great potentials programmers have such keen great sense for. I feel there is an over-regulation, an over-pressuing on our social systems these days. "Overnight Pizza and the Consistent Unreliability of Expert Guidelines"[2][3] is recent article ostensibly about Expert Opinions & the low-information-density environments such guidelines are crafted in & for, but it's also an incredible story about social pressure, the urge to be right, about the emotional high one gets from being certainly completely correct & proper & everyone else being a fool. It's about overly absolutist perspectives, that don't allow for a bigger continuum of opinions. And I think a lot of software folk have turned in to the "overnight pizza will kill you" camp: they have encountered some parts of the maelstrom, tasted what the uncivilized is like, and their reaction is to build & fortify against the encroaching dark, to turtle up, & build strong best practices & robust processes. Which is both noble, respectable, given the maelstrom of software, but also... I feel like our lack of adventurous spirit often holds us to petty tasks, and keeps us from exploring & seeking better lands, with much richer yields. [2] https://residentcontrarian.substack.com/p/overnight-pizza-and-the-consistent https://residentcontrarian.substack.com/p/overnight-pizza-an... [3] https://news.ycombinator.com/item?id=26635856 https://news.ycombinator.com/item?id=26635856 Programmers, the New Kingmakers[4], are also in an enormous tension. Business's often proclaim that they want go-getter attitude, that they folks focused on landing wins, making sure their every effort helps the customer. But often programmers are very very alone in seeing a bigger picture, seeing long term costs, seeing how the business is creating amateur grade software that will not hold up. Programmers can feel under strain to deliver, and conservatism naturally results, a concern that things will fall apart, that core formative activities won't have time to occur or mature, that the result will be disorder. Few companies internalize & earnestly grapple with an understanding of how the sausage is made, programmers often view other people as viewing them as resources, to be used, tapped, often without awareness or responsible handling, without understanding that the magic has a price, that it's stacking up. Those closest to the craft have a deeper insight into how the business's "win orientation" is creating (& compounding) amateur losses, and they feel enormous protectivity: that they must claw from the business the good acts it cannot see and that it needs. [4] https://thenewkingmakers.com/ https://thenewkingmakers.com/ But that's not the worst part of the business environment to me. The worst to me is writ large in "Why software engineers should be CEOs"[5]. We are incredibly creative, we see enormous potential at every step. Only rarely does the business let us drive towards the true fantastic excellences that we dream of pursuing. Just as the business doesn't understand the loser's game challenges that are all over the place, oh, sad, the business also does not have anywhere near the vision or creativity of the individual, of the coder, who sees possibility & value oozing out of so many areas, often so untapped. And programmers are not put into decision making roles nearly enough, not given structure & the attitude that they can strike, that they can chase down big game, game the rest of the company often has a hard time seeing. The socialization processes that work places must go through to allow commitment are very high, and so programmers simply do not have the time, ability, or often even the common language to get the businesses play the winning game. We must trust that the business somehow is aligned to let us make them kings, rather than taking an active stake in pushing the business towards their would be kingdomship. [5] https://www.tlt21.com/why-software-engineers-should-become-ceos/ https://www.tlt21.com/why-software-engineers-should-become-c... Beware committing your life to mastering the losers game!! You are the dreamer of dreams. It hurts, it's always a challenge, but please, dear fellow programmer, stay in touch with your noble (& a little bit wilder) selves. I believe in you.

havkom 6y ago

The ”game” of software development is rather ”won” by understanding the surrounding business and delivering on those goals rather than any, by software developers made up, “goals” about “standards”, “unit testing” or “SOLID design patterns”. The game is also about good co-operation, helping colleagues succeed without imposing dogmatic requirements, and making friends with influential people connected to the software development team. This is rather an article about loosing the “game”.

emsy 6y ago
Dogmatic rules are for people that don’t know yet when to break the rules. Ironically, a lot of lead engineers I worked with don’t know that this is what dogmatic rules are for so they impose them to appear competent.

uberswe 6y ago

The author makes a list of things a “professional” developer uses. Among these are SOLID principles and design patterns. While they are good things to understand, I have met many developers who follow such principles without thinking and try to apply them to every task. This can make something really simple very complex when it doesn’t need to be.

abledon 6y ago

>80 percent of software developers are amateurs and 20 percent professionals. Why do I say this? >Amateur software developers dislike - Standards - Unit testing - Design patterns/SOLID principles - Learning and setting DevOps and ALM (They like using it) - Fixing the build - Code reviews - Code Analysis/Solution checking What a troll statement, no way do 80% of software developers dislike those things.. maybe.. 20%?

foobarian 6y ago
Let's not even get into definitions of amateur and professional. Working with this guy? Hard pass.
alexjplant 6y ago
I've had the misfortune of working at a few places were many/most of these things were pretty universally frowned upon. > - Standards Resistance to using formatters and linters because they prevent you from merging code more quickly; "it's annoying". Two of the two-dozen devs on the product decide that they want to use NetBeans instead of Eclipse even though the formatter is built for the the latter and everybody else uses it so they can't format their code properly. > - Unit testing I recently went four years without writing a single unit test professionally. When I _did_ write unit tests I worked on one team where the only important metric was coverage percentage, not corner/edge cases or intentionally trying to break the software. People would write tests for auto-generated getters and setters in C#. That's right - they would _test the compiler_ just to satisfy a business metric. > - Design patterns/SOLID principles My tech lead at a previous job refactored a pretty substantial service I wrote with no team input to remove any semblance of organization or convention. The repositories, factories, and facades I built got merged into a giant single "helper" object just to follow some weird anti-pattern that they'd established. It wasn't testable, there was no separation of concerns, and it ended up being nigh-unreadable. > - Learning and setting DevOps and ALM (They like using it) > - Fixing the build I've been the "CI guy" at almost every software job I've had because some people are afraid of the command line and lack an understanding of the build tooling outside of the three SCM operations they know through Tortoise and the play button in their IDE. I could go on but you get my point. Software development is a vast industry and there are some pretty dark corners. For every high-performing team that has tech-savvy devs there are body shops full of people that are trained by rote to "build software". It's not pretty.

crazypython 6y ago

> Unit testing In the game development, videogames are primarily tested by humans. Games are highly interactive pieces of software often running on a variety of hardware with complex agent-based simulations. Are all game developers "amateurs"? I don't think so.

_3u10 6y ago
Yeah, I couldn’t find the dev ops folder or the unit test folder in the Linux kernel sources either. Any idea on how they get the kernel to scale without kubernetes?
watwut 6y ago
Videogames overall are primary tested by humans, but smaller components inside them do have unit tests. Unit test and integration testing are two different things.
- crazypython 6y ago
  Hmmmm, how would you test, for instance, a rendering engine?
  - watwut 6y ago
    Majority of it are pure calculations that are easy to test automatically. Was this even serious question?

renewiltord 6y ago

Nothing particularly unique about the software part. But the quoted text is interesting: that is kind of true about pro vs amateur tennis (or table tennis or badminton). Didn't quite notice it. Still, amateur tennis is funner when you play to win the point :D

agentultra 6y ago

I too have been in software development for 20+ years. The most effective thing we can do to write better software is to get good rest, reduce stress in the work place, and learn to write and communicate effectively. After that comes skills with the tools and processes around writing software: technical, mechanical skills that can be taught and managed. You need a mix of people from different skill levels to make an effective team. "Amateur," or "junior," or whatever you classify folks with less experience as bring a lot of energy and enthusiasm to a project. They're often eager to learn and many don't know what isn't possible yet and bring fresh ideas to the table (not every idea is a good one but it's nice having folks on your team who are keeping everyone out of a rut). On the opposite end I don't think you can have "senior" or "professional" developers without anyone to mentor or train and work with. In order to solidify your understanding of a topic you have to be able to communicate it to an audience with less specialization and understanding than you. Knowledge takes time to develop into facts we can take for granted. Update: If you're interested in empirical evidence of the effectiveness of various software development practices, a handy, light resource: https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ tldr; very few practices we eschew as a professional obligation, like being diligent about writing unit tests, have little evidence to support their effectiveness in reducing errors. The things that do work: sleep, low stress, writing, and probably code review.

dasil003 6y ago

Interesting idea, but doesn’t really hold up because software development is not adversarial. Now security on the other hand...

parasubvert 6y ago

I’ve seen plenty of “amateurs” write unit tests, CI/CD, adhere to standards, pair program or deal with code reviews, etc. Inevitably this has 100% to do with the culture of the work environment. Either those things are mandatory, enforced by both peers and management, or they’re optional. This reads like a rant about a low discipline organization, where it’s impossible to change the culture, and thus easier to crap on those who don’t know any better.

ambientlight 6y ago

Title could have been less clickbaity

_3u10 6y ago

If you’re tired of software dev try http://programming-motherfucker.com/ http://programming-motherfucker.com/ instead.

zwieback 6y ago

To be fair, a lot of traditional science and engineering follows the same pattern. I'm a SW dev embedded in an R&D engineering organization and the main difference is that SW development has faster cycles and less established practices but if you scale up SW dev timelines to match ME and EE cycles it's not that different. Preventing bugs is something especially our materials and system interaction engineers are very aware of. You don't want a consumer product to fail in the field and cause damage or harm so that's goal #1.

ChrisArchitect 6y ago

more previous discussion from a few days ago: https://news.ycombinator.com/item?id=26630731 https://news.ycombinator.com/item?id=26630731

avelis 6y ago

The title is a little clickbaity. In my engineering management experience I instill the following values to decent success. * Write tests for almost all code. * Code review with peers. * Deploy frequently with roll-backs. * Reward each other when things go well. * Help each other when things go wrong. This leads to high test coverage, good knowledge sharing, progressional changes, and a healthy work culture.

pinkybanana 6y ago

I was at a startup, we almost never wrote tests, just hacked like amateurs in the way this guy seems to despite. But we managed to sell the startup and got rich. Now the software we hacked together is being maintained by professional programmers. They have tests and all those fancy processes and what not. They get paid nice salary but they'll probably never get rich like the founder programmers. I'm pretty sure also we wouldn't got rich with writing the unit tests and what not. We just needed to implement it quickly and provide good enough version. To me the writer sounds more like loser than the amateurs he mocks. But I guess it is on whatever side of the fence you are. Nothing wrong preferring one or another.

meiraleal 6y ago
Perfect. Although I agree with the writer, context is everything. It is like static vs dynamic typed languages. If typed was really better for every case, dynamic wouldn't be as big (or bigger).

TheCapn 6y ago

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. Whoever had written this project before me wrote no tests, and basically brute forced features to work. A dropdown box that loaded options dynamically based on other user selections had 18 variables buried in the code where 8 of them were either unused or redundant. For a fucking dropdown box? I told the PM 1 week in that I'm not going to make the delivery deadline and he should be advising the client of such. --- I don't want to talk bad of my coworkers so I'll just say this. I'm the only developer in my company with a software background. Everyone else is electrical engineering/tech and it shows when you review their code. Comparing this "Amateur" vs. "Professional" article to what I am currently going through feels almost cathartic knowing this is something widely experienced in the field. I truly love my job, but some days, like these last days, really make me want to unplug from the world and go live in the wild because not only do Amateurs make these mistakes, they're also blind to the Professional ways of approaching work. It almost felt like an argument at times convincing him that this "extra" work that was neglected previously is necessary and should be factored into everyone's projects, not just mine.

danans 6y ago
> What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.
- hnarn 6y ago
  If you ask someone to give you an estimate for work needing to be done on your car, not only is it obvious that they will have to look at the car first, it's also obvious that the estimated cost and/or time may and often will overrun (although you're normally notified and asked before it does). It seems like both of these things should be equally obvious in software.

cperkins 6y ago

I think the "winners game" vs. "losers game" insight is interesting and there is some value in applying it to software development. But I don't see it as a revolutionary insight, anything that's going to radically change anyones understanding. The article has other problems, but overall it's just lukewarm. To my mind, the main issues in software development are complexity and imperfect knowledge. We've developed a lot of practices like unit tests and code reviews which help us defend ourselves, but, ultimately, for any non-trivial software it seems like a losing battle, or if not losing, then the progress is slow and difficult and tenuous. (like trench warfare).

renox 6y ago

In theory, that's true, unfortunately often "professionals" write poor code like amateurs and then spend all their time in debugging :-(

austincheney 6y ago

> Amateur software developers dislike While the rest of the list is valid the author could have stopped at the first item Standards and still have made his point. Perhaps the most perfect example of that is why JSON won versus XML for data serialization. Many people will claim that it's because XML is bloated. After all this was the primary argument of JSON's inventor Douglas Crockford. They aren't wrong, but its not why JSON won. JSON won because it's specification is tiny. When all the boilerplate is scrapped off the latest version is about 5 tiny pages of text any high school student can understand: https://tools.ietf.org/html/rfc8259 https://tools.ietf.org/html/rfc8259 Compare that to XML: * XML - https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ * XML Schema - https://www.w3.org/TR/xmlschema11-1/ https://www.w3.org/TR/xmlschema11-1/ * XSL - https://www.w3.org/TR/xsl11/ https://www.w3.org/TR/xsl11/ Those are HUGE and they are written to conformance precision for implementation engineers. No high school student will ever read any of that for pleasure. I remember reading those when I first entered software development and absolutely everybody thought I was out of my mind and promptly discarded everything I said if they didn't already know it. I remember that being particularly frustrating because ever recommendation or proposal had to read like a pitch deck to a VC, but if I wanted to do that instead of engineering or product development I would be brand evangelism or merchandising. XML for a data conveyance medium is extremely powerful, but in practice this is completely irrelevant. XML is a world unto itself in all of its capabilities and potential, but that doesn't matter if nobody is using it. Most Americans, regardless of their actual educational attainment read at a 9th grade level (high school freshman). That applies to entry level software developers as well. Computer scientists and inventors are not the average of software developers. On one hand this is great, because I truly believe anybody can be a software developer and write really bad code. On the other hand this is horrible, because many people are code monkeys that write either bad code only or are fundamentally limited to a small subset of solutions limited by a small subset of tools.

deleted 6y ago

[deleted]

karmakaze 6y ago

A vapid post that doesn't cover a vast range of 'winning' development strategies that aren't about 'not losing'. Direct things like really understanding the problem you're trying to solve; Making invalid states unrepresentable; Using composable techniques to separate parts of a problem that can be combined safely and meaningfully.

bokohut 6y ago

My first exposure to computers and writing code was on an Apple in the mid 1980s, I was hooked at a very young age. Since that time I have obtained a higher education degree in software development as well as architected, coded and managed entire enterprise platforms for multiple businesses I have founded. As an entrepreneurial software development loser I stand proud and sm:)e.