Jasper Sprengers

Indeed, that’s the state of the art this moment, but there’s no telling how quickly it will get more sophisticated. It will not just be about stringing together code snippets based on a statistical model.

Understanding and editing generated source code will be a crucial skill in the coming years. And you always need to tell the machine what to write, which is the hardest part.

Yes indeed. For years I’ve been hearing that contemporary pop music all sounds the same, and now we have the science to back it up. People don’t value originality, it seems, or they just prefer what they know.

https://www.theguardian.com/commentisfree/2023/jul/26/taylor-swift-rules-the-airwaves-but-thats-bad-news-for-music

A likely gateway library to Scala ;-)

These component tests indeed require a Spring context (not always with an http server), but that is a one-time penalty for the entire suite. Tests aren’t noticeably slower than regular unit tests, although when measuring in millisecs they probably are. When you limit yourself to only testing the crucial scenarios that way, it is acceptable.

Thanks for your insights. The concepts of ‘unit’ and ‘integration’ are indeed confusing. Everything can be considered a unit when viewed within a hierarchy, and there is always integration of sorts at play.

In our Spring microservices landscape we focus on component tests, i.e. tests that consider a single deployable with its server runtime, but with all networked dependencies mocked, so they can run locally or in the pipeline. We don’t do integration tests.

You over-estimate me :-)
I don't have a CS degree, so I have various holes in my abilities, maths being one of them.

Yes, developers are drawn to over-engineering like moths to a flame - with similar results. (funny analogy; not mine)
I read Essentialism too a couple years ago. In a similar vein, you might also enjoy Four Thousand Weeks by Oliver Burkeman.

Thanks for your insights and I agree that security testing calls for very specific skills.
What you call a ‘software bug’ I would prefer to call a functionality defect (caused by faulty coding). Security vulnerabilities can also be introduced by code, but even more so by the way the software is configured and deployed, which may be out of the original developers’ control. All the more reason why we can’t reasonably expect them to take responsibility for all aspects of security.

I’ve bookmarked this artice! Very nice overview. I’ve used many of them already over the years. If I may add to question 17 on languages and stacks: versions matter. If they’re still at Java 8 (or lower!), it screams unmaintainable legacy, mountains of technical debt or a CTO who doesnt see the point of keeping up with the state of the art. All are red flags.

Thanks for your insights! There was a time, not so long ago, that I wrote a single unit test class for every source class, mocking out every dependency, and ending up with tests consisting of 90% tedious ‘arrange’ sections. And then I wondered why refactoring was such a pain, because the tests were so tightly bound to implementation details.

Thanks for your comment, but the link to the article is missing.

It's not all bad news, though. A lot of really difficult stuff about low level concurrency has been removed since I did the SCJP 6 several years ago. Now it's discouraged to fiddle about with the Thread methods directly and use the (scheduled) executors instead. I do consider that progress.

Well, I still do a fair bit of pooh-poohing myself, especially about such nonsensical trick questions like a public method that has the same name as its class, but also a void return type. Hence it is not a constructor. Madness!

I'll see when I get there ;-)

It’s certainly a double-edged sword. Perhaps modern photo cameras are also a good analogy: any photography course will advise you to turn off manual exposure and focus, and learn how the manual settings affect the picture. You learn a lot in the process.

Thanks for your comment. I don't think the problem is specific to younger developers. The tendency to rely less and less on our memory skills affects everybody, old and young. And it has far wider implications than coding.

Thanks for your comment. In my current project we also use Cypress and its own mechanism for faking backend responses, which is less hassle in that it doesn't involve starting a karate server, but is more handiwork in writing the responses.
I suppose an integration test focuses on the points of integration between two or more separately deployable components of a system. Testing with a real database or between microservices would be an example. It sits higher up in the test pyramid than a component test.

Nine years later Joel wrote glowingly about the duct tape programmer:

https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/

Such a radical change of heart we call in Dutch “voortschrijdend inzicht”. ;-)

So true. People like Steve ‘Don’t make me think’ Krug and Jakob Nielsen have been stressing the importance of usability for decades. But too many sites that stand to gain (also financially) from a great user experience look like they were built by people with no interest or experience in the matter.

Thanks for your insights. I notice while working remote that interruptions often take shape in DM messages that have the immediacy of a phone call in people’s expectation, i.e. not asynchronous at all compared to an email. That’s problematic.
You mention two blocks of three hours uninterrupted focus. In my experience that’s hard to achieve (dreaded meetings), but also from a concentration/productivity point of view. An hour’s full focus with ten minute admin/coffee works bettrr for me.

Interesting and varied selection, although I do think the original Gang of Four book shows its age. Many previously ubiquitous patterns (e.g. decorator) are now semi-obsolete thanks to more powerful languaged like (suprise!) Scala.

I wouldn't claim that Scala isn't well thought-out, but there's definitely a deliberate design philosophy of brevity over readability.

Good points, and I think it is very telling that a JVM language like Scala, which is much more feature-rich, has not made much of a dent in Java. It can be infamous for its unreadability because of everything you are allowed to leave out if the compiler can infer it. Not the way to go.

Thanks for those helpful insights. Spring adds a lot of hidden surpises in this superficially simple feature. All the more reason to test these interactions properly and in detailed integration tests against a real database.

Fascinating read. I like the analogies with flying and language learning, which is of special interest to me, as I trained as a linguist. Becoming expert at a foreign language means you apply the rules of grammar intuitively and can no longer explain why a sentence is grammatical or not, just like native speakers. For expert programmers this means they must be able to explain their hunches well if they want to successfully coach juniors.

Great article, but I beg to differ with your claim that “No one writes unreadable code on purpose”. There’s a difference between deliberately writing unreadable code, which feels like an act of sabotage and indeed very few people do if they want to hold on to their job. But there’s wilful intent and there’s neglicence. Making yourself well understood (not just in code) is hard work that people often neglect. It’s a selfish omission because it wastes other people’s time. Being Dutch myself, English doesn’t come naturally. It took hard work.

I'm suddenly reminded of a developer colleague who was also a very proficient chess player. He said something similar. Professional players don't overlook obvious opportunities and pitfalls.

Nice comparison! I always like original analogies. Yes, it's crazy how we trample on the low hanging fruit, pardon my metaphor.

Thanks for your contribution. Yes, it's true that the Scrum guide leaves many details open. But sometimes illogical or counterproductive practices become so ingrained that I feel it necessary to remind people.

Yes, I wish I could remove them myself. I'm the one getting the mails "Your article has received a comment" ;-)

Thanks for this article. I think it's time to conclude that many of the common conceptions about agile are misguided and have turned into dogma: the over-emphasis on programming as a collective effort, the tedious sports analogies and the very limited actual team autonomy. What's left is going-through-the-motions ceremony.
Why still call it Agile? Sometimes a re-evaluation of ideas however constitutes a departure of principles that calls for a new name, not version two. Organizations coming to terms with their disappointment about old-school agile may not warm to the idea if all they expect is an upgrade.