> 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.
I think you're right, but I also think the author isn't necessarily wrong.
Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up.
I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on getting it over the net as simply as possible, the end result usually means less code that's easier to understand.
Example: junior dev needs to write a data transformation pipeline. They write a microservice and deploy it in Docker on Kubernetes. They do a lot of hand-wringing about reactive design and non-blocking I/O. They end up wrestling with the deploy and getting it done on time. All it needed to be was a simple single-threaded command line utility.
In 15 years, I've seen this story play out tons of times... I'm basically watching devs trip over themselves. I'm not saying I'm perfect either, this has happened to me too.
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).
I feel like it’s the word ‘goal’ that makes one stumble here. I agree that he is not really describing the ‘goal’ of software development. He’s describing how to succeed at software development in order to reach a larger goal.
And although it took me a while to understand what the author is getting at, I do kind of see his point which in my mind could be summarized as: slow and steady wins the race. Or: In order to speed up (in the long run), slow down (in the short term). Be conservative, be thorough, understand that developer productivity isn’t about that LOC per x unit of time.
One analogy that comes to mind for me is Formula 1. Sure, it would be faster, right now, to just not pit. You would have to drive into the pit, stop and wait for the tyres to be changed and drive out again. Meanwhile your opponents are zooming past you out on the track. But if you don’t pit, soon enough your tyres will be worn down and it becomes impossible to keep heat and performance in them, and after a while longer you might even have to stop completely due to a puncture.
The ‘pitstop’ could be anything that ensures productivity in the long term and as such helps in reaching the final goal, and those are the things that take a professional to understand the importance of.
I didn't read the article the same way. I think we're all, in a certain way, amateurs, at least in some cases: when we're rushed, stressed, distracted, or all three. As a project accumulates people working on it and, crucially, as existing code is modified and added to, the probability that you'll introduce a bug approaches 1.
I think the article is saying we should focus on tooling that makes natural human errors less likely, instead of trying to focus on writing more code: in other words, write less code, ship it once without errors, instead of writing more code and having to go through the dev to prod feedback loop repeatedly. The tooling that helps you do that are DevOps practices, testing (and testability), simpler/more conservative design, and some time spent thinking about how to construct the software (or reconstruct it, when modifications are needed).
I always read these and wonder "So uh, did you go and talk to the guy and help him out?"
Now maybe they did and the other person refuses to listen (not common in my experience), but I always wonder... you can't just make up 'rules' and expect folks to magically write good code because they followed a rule.
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.
> 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.
I wonder what his recruitment pipeline looks like where 80% of engineers end up not being productive.
What is the alternative? If you let shoddy code in, it is difficult to get rid of and it may become a foundation for even shoddier one (if you let that in, then why you won't let this in).
> The goal of software development is to create software in support of some greater mission
If that's the goal - the only goal - then all code is equal, and it doesn't matter how it's written. So... go crazy? Use global variables and goto statements? Hardcode path names and don't bother with build scripts? Writing software that works is challenging, but writing software that can be safely modified is even more so.
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.
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.
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.
I think the heart of this isn't devs changing jobs. It's execs. I know plenty of devs who will be "irrational" about quality in that they build for sustainabilty and longevity far beyond their personal economic incentives.
But when those same devs go up the chain to improve practices or clean up tech debt, they rarely end up happy. I think that's because executive turnover is also fast and the rewards for underinvestment are much larger. Executive compensation is often tied to stock price and other short-term metrics, and executive tenure is also quite short. That gives them a strong incentive to cut anything that pays off over the long term.
Which I think ties back to his professionals vs amateurs thing. One thing that distinguishes professionals is standards. Doctors won't prescribe you anything you want. Real engineers will refuse to build things that will collapse. But a lot of devs are more minions than professionals; if the boss says to build X, they'll build X. Whether that's good for the company, the customers, or society isn't relevant.
Also there can be other real life business constraints. Sometimes the project need more devs but there aren't any to add. Sometimes the deadline is truly set in stone and if you miss it you are truly fucked. In times like these you have to cut corners and these are the easiest corners to cut for short term speed.
"Amaterur vs professional" feels "Good vs Bad" for me but real life is never as simple as that.
OTOH, business itself cannot spare any manpower to maintain old code.
Not their fault either, because maintaining old code is hard, frequently will introduce new bugs, and potentially halt business. Less hope for migrating into newer engine / language.
It's simply that software development is hard and we lack standardization more than any other industries.
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.
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.
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.
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.
There's very much almost a meme of those programmers who tell us all how everyone else is doing it wrong ... but their whole idea about who is doing it wrong seems to be entirely driven by how often they're inconvenienced by other people's code, but never account for how often others are inconvenienced by their code.
I get inconvenienced by other people's code all the time, but it's so easy to assume when you're looking at the bug "they should have known this was going to happen / tested for this" when you started your investigation knowing the trigger for the bug.
Anecdotal story: I had a bug a few weeks ago that all sorts of people thought was really dumb / obvious / shouldn't have happened. I checked... the code hadn't been changed for FIVE YEARS. Nearly every customer we had ran this code for five years. Maybe I feel that they should have had a catch for the situation that occurred, but whomever wrote it wrote code that lasted bug free for five years ... maybe they weren't dumb and they knew something I didn't?
> developers forget that the goal is to ship software and instead focus on doing everything the most correct
I'm far, far more frustrated by developers who focus only on shipping software and making dates by cutting corners wherever they can and leave everybody else to deal with their gigantic mess later.
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)
I see this as a false dichotomy - the real most correct way is less expensive, it's just that quite often people who think they're aiming at perfection are instead actually experimenting with different approaches at random with no clear benefit.
You don't need to cut corners to achieve cost effectiveness and tech debt is just that - debt, which always has to be paid eventually - either through expensive bugfixing, a rewrite or bad user experience.
The project's I've been in that went over budget usually had one or more of the following:
-Too large of a scope vs budget.
-Bad or no architecture whatsoever.
-Increasing personnel instead of reducing scope.
On the other hand projects with an architecture, a set of clear conventions and flexible scope fared much better.
It's also possible to try to strike a balance and to get it wrong. It is also possible to strike the right balance proportionally but be in a business environment where your best effort results in failure.
Maybe I'm weird but I think I am pretty average at programming. Not great, not terrible. I get things done, more slowly and with more bugs than some, more quickly and with fewer bugs than others.
Of course most employers probably aren't looking for an "average" programmer, but I haven't found that they usually ask me to rank myself relative to others.
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.
I am one of those that can’t get started because perfection and peer review is in my head. I blame it on Stackoverflow making me feel like a moron every time I ask something.
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.
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.
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).
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.pd...
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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..
[+] [-] terracatta|5 years ago|reply
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.
[+] [-] scottious|5 years ago|reply
Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up.
I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on getting it over the net as simply as possible, the end result usually means less code that's easier to understand.
Example: junior dev needs to write a data transformation pipeline. They write a microservice and deploy it in Docker on Kubernetes. They do a lot of hand-wringing about reactive design and non-blocking I/O. They end up wrestling with the deploy and getting it done on time. All it needed to be was a simple single-threaded command line utility.
In 15 years, I've seen this story play out tons of times... I'm basically watching devs trip over themselves. I'm not saying I'm perfect either, this has happened to me too.
[+] [-] protonimitate|5 years ago|reply
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).
[+] [-] slowwriter|5 years ago|reply
And although it took me a while to understand what the author is getting at, I do kind of see his point which in my mind could be summarized as: slow and steady wins the race. Or: In order to speed up (in the long run), slow down (in the short term). Be conservative, be thorough, understand that developer productivity isn’t about that LOC per x unit of time.
One analogy that comes to mind for me is Formula 1. Sure, it would be faster, right now, to just not pit. You would have to drive into the pit, stop and wait for the tyres to be changed and drive out again. Meanwhile your opponents are zooming past you out on the track. But if you don’t pit, soon enough your tyres will be worn down and it becomes impossible to keep heat and performance in them, and after a while longer you might even have to stop completely due to a puncture.
The ‘pitstop’ could be anything that ensures productivity in the long term and as such helps in reaching the final goal, and those are the things that take a professional to understand the importance of.
[+] [-] potatoz2|5 years ago|reply
I think the article is saying we should focus on tooling that makes natural human errors less likely, instead of trying to focus on writing more code: in other words, write less code, ship it once without errors, instead of writing more code and having to go through the dev to prod feedback loop repeatedly. The tooling that helps you do that are DevOps practices, testing (and testability), simpler/more conservative design, and some time spent thinking about how to construct the software (or reconstruct it, when modifications are needed).
[+] [-] duxup|5 years ago|reply
Now maybe they did and the other person refuses to listen (not common in my experience), but I always wonder... you can't just make up 'rules' and expect folks to magically write good code because they followed a rule.
[+] [-] eithed|5 years ago|reply
[+] [-] 908B64B197|5 years ago|reply
I wonder what his recruitment pipeline looks like where 80% of engineers end up not being productive.
Sounds like he's hiring wrong to begin with.
[+] [-] varispeed|5 years ago|reply
[+] [-] eplanit|5 years ago|reply
[+] [-] commandlinefan|5 years ago|reply
If that's the goal - the only goal - then all code is equal, and it doesn't matter how it's written. So... go crazy? Use global variables and goto statements? Hardcode path names and don't bother with build scripts? Writing software that works is challenging, but writing software that can be safely modified is even more so.
[+] [-] TheCapn|5 years ago|reply
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.
[+] [-] preommr|5 years ago|reply
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|5 years ago|reply
[+] [-] wpietri|5 years ago|reply
But when those same devs go up the chain to improve practices or clean up tech debt, they rarely end up happy. I think that's because executive turnover is also fast and the rewards for underinvestment are much larger. Executive compensation is often tied to stock price and other short-term metrics, and executive tenure is also quite short. That gives them a strong incentive to cut anything that pays off over the long term.
Which I think ties back to his professionals vs amateurs thing. One thing that distinguishes professionals is standards. Doctors won't prescribe you anything you want. Real engineers will refuse to build things that will collapse. But a lot of devs are more minions than professionals; if the boss says to build X, they'll build X. Whether that's good for the company, the customers, or society isn't relevant.
[+] [-] croo|5 years ago|reply
"Amaterur vs professional" feels "Good vs Bad" for me but real life is never as simple as that.
[+] [-] 908B64B197|5 years ago|reply
[+] [-] fendy3002|5 years ago|reply
Not their fault either, because maintaining old code is hard, frequently will introduce new bugs, and potentially halt business. Less hope for migrating into newer engine / language.
It's simply that software development is hard and we lack standardization more than any other industries.
[+] [-] agentultra|5 years ago|reply
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/
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.
[+] [-] duxup|5 years ago|reply
>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.
[+] [-] PragmaticPulp|5 years ago|reply
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.
[+] [-] duxup|5 years ago|reply
I get inconvenienced by other people's code all the time, but it's so easy to assume when you're looking at the bug "they should have known this was going to happen / tested for this" when you started your investigation knowing the trigger for the bug.
Anecdotal story: I had a bug a few weeks ago that all sorts of people thought was really dumb / obvious / shouldn't have happened. I checked... the code hadn't been changed for FIVE YEARS. Nearly every customer we had ran this code for five years. Maybe I feel that they should have had a catch for the situation that occurred, but whomever wrote it wrote code that lasted bug free for five years ... maybe they weren't dumb and they knew something I didn't?
[+] [-] commandlinefan|5 years ago|reply
I'm far, far more frustrated by developers who focus only on shipping software and making dates by cutting corners wherever they can and leave everybody else to deal with their gigantic mess later.
[+] [-] danybittel|5 years ago|reply
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)
[+] [-] Tade0|5 years ago|reply
You don't need to cut corners to achieve cost effectiveness and tech debt is just that - debt, which always has to be paid eventually - either through expensive bugfixing, a rewrite or bad user experience.
The project's I've been in that went over budget usually had one or more of the following:
-Too large of a scope vs budget.
-Bad or no architecture whatsoever.
-Increasing personnel instead of reducing scope.
On the other hand projects with an architecture, a set of clear conventions and flexible scope fared much better.
[+] [-] afarrell|5 years ago|reply
https://www.youtube.com/watch?v=t4A-Ml8YHyM
"It is possible to commit no mistakes and still lose. That is not a weakness. That is life."
[+] [-] FeteCommuniste|5 years ago|reply
Of course most employers probably aren't looking for an "average" programmer, but I haven't found that they usually ask me to rank myself relative to others.
[+] [-] monkpit|5 years ago|reply
[+] [-] culopatin|5 years ago|reply
[+] [-] thouitsme|5 years ago|reply
[+] [-] bfgoodrich|5 years ago|reply
[deleted]
[+] [-] MattGaiser|5 years ago|reply
[+] [-] pinkybanana|5 years ago|reply
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|5 years ago|reply
[+] [-] Fred27|5 years ago|reply
[+] [-] cableshaft|5 years ago|reply
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.pd...
[+] [-] duxup|5 years ago|reply
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.
[+] [-] at_a_remove|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] zabzonk|5 years ago|reply
[+] [-] joncp|5 years ago|reply
[+] [-] xwolfi|5 years ago|reply
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.
[+] [-] parasubvert|5 years ago|reply
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.
[+] [-] odipar|5 years ago|reply
"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.
[+] [-] varispeed|5 years ago|reply
[+] [-] quonn|5 years ago|reply
[+] [-] damau|5 years ago|reply
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.
[+] [-] lmilcin|5 years ago|reply
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|5 years ago|reply
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...
[+] [-] onion2k|5 years ago|reply