41–50 of 159 posts
That article taught me more more about tennis than about software development.
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...
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..
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.
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 deve…
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?
Earlier quoted context omitted.
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.
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 cons…
I know because I did, multiple times. It’s futile. Your best move is to leave in that situation.
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 deve…
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.
>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%?
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..
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.
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.
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 deve…