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
Software development is a loser’s game
51–60 of 159 posts
Re: Software development is a loser’s game
#52> 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.…
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).
Re: Software development is a loser’s game
#53Earlier quoted context omitted.
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.
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.
> 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.
Re: Software development is a loser’s game
#54An 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 deve…
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.
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."
Re: Software development is a loser’s game
#55>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%?
Let's not even get into definitions of amateur and professional. Working with this guy? Hard pass.
Re: Software development is a loser’s game
#56The ”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…
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.
Re: Software development is a loser’s game
#57One 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 bett…
The TDD advocates I have been exposed to are mostly cargo culting consultants and this alone makes me very sceptical. It has some good core ideas but I find that in practice it leads to unit tests that are highly coupled to implementation details. Quick to execute but almost worthless from a test perspective. Its best to throw them out after the inital implementation is done since the usually just become a burden to maintain. Black box at system boundaries are the only tests that bring value long term in my experience. I would really like to hear more details about projects that use TDD and how they use it a few years down the line. All I can find are toy examples..
Re: Software development is a loser’s game
#58That article taught me more more about tennis than about software development.
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.
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.
Re: Software development is a loser’s game
#59Because 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 (lowe…
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.
Software today is a complicated mess. On the consumer side, peoples minds are so fickle and they want the latest shiny object or app; on the software side, companies are constantly inventing new ways to do the same old thing; hardware is getting tossed in the dump, when it is actually still very viable.
It's fascinating to see what people are doing with old hardware like Commodore 64, because it's understandable and doesn't change at this point. If we can use hardware that is almost 50 years old, why are cycling through things so rapidly?
Re: Software development is a loser’s game
#60Because 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 (lowe…
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.