Edit: Now also available on my blog.
I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it. - Bill Gates
...
For further actions, you may consider blocking this person and/or reporting abuse
As usual, comments are welcome.
This was an interesting one! Great writing and a good read.
I liked this bit in particular:
Haha, well said. That's gonna stick with me.
Really nice one....
"A week of coding can save on 30 minutes of planning" :D
My buddy once said "Writing great code is easy, it's the coming up with it part that's hard".
But seriously, I agree with the need to reducing complexity, I always go back to telling folks that old adage about the human brain only having RAM for like 5 things.
To this end, I think TDD is helpful, even if you have to write a couple of tests that will ultimately be rewritten - it's a way to leave a breadcrumb to return to later without sweating about it too much. It's an unfortunate fact often missed in TDD talk that to write proper specifications, you need to have some code for things to start falling into place. It's an iterative process - stumble about a bit, drop some breadcrumbs, hit on the core behavior and the structure you want for it, specify that, get something working, return to breadcrumbs.
It's a sort of journey from the very detailed out to the most overarching and back again, but now with a clue about what needs to be built, and how.
The level of problem you are solving contributes to code complexity. The way you are solving it is is contributed by your level of expertise and your target users, their platform, their adoption, their preferred requirements.
Using your brain is the best part of being an engineer.
I cannot agree with you enough βΊοΈ. Thanks a lot for illustrating it.
A reassuring sentence I repeat to my customers is,
"If we can define it, I can create it".
Thus, the burden of hard thinking is shared with the customer, and the expecations won't go wild.
Moreover, I really need to make small commits. Very small. As most of my coding experience is through a textual ssh screen, a unit of commit will usually span just a few file changes, done one by one π, of course.
And, in the really dangerous field of service management, I constantly oppose changing more than one thing at a time. This, to be hands on when something breaks, and reduce the debt.
I like the links, but that really triggered my ADHD haha. I do feel like the Grug at times from the very, very, bad link thus google searching and found your article. And I totally understand the TDD dilema, AND TDD is awesome, and this is the first time I have seen BDD, which could also be great intertwining the two.
One can argue that quick code prototyping is actually a way to build understanding about the task and if necessary to rewrite, that's fine.
Expecially in old projects, they already use existing frameworks for achieving specific objectives. So often I find it necessary to do some exploratory coding before figuring out how exactly something needs to be implemented in a consistent for the project approach. This is especially true with "opinionated" frameworks, where going on your own way is a path covered with tears...
So it depends.
Actually I find it hard when I have to figure out how to change something that 100 other things depend on. More often than not, new features are on the fun side.
As a "seasoned" software engineer, my clients expect me for solving their problems by thinking the issues through, not just through coding. Some problems are too complicated for one person to solve through coding alone and need a coordinated response.
Adopting a solution with insufficient thought is only creating problems for later (aka Technical Debt). Whilst this might sound a good strategy for career protection, the reality is your clients will not be impressed.
I suspect it will be those jobs that do not require human brain power that will be most at risk of being replaced by AI.
I envy you your clients value your planning. I had to take this by force.
I agree and this is why thinking long and hard at the right time is important.
Great writeup. I am going start practicing this in dev for today.
My favourite line comes from your post on Atomic Git Commits
Thank you
It 's on what one should stay focus and concentrate. Not to drain our mental energy.
Interesting.
The Prime mentioned π₯
Let's goooooo π₯π
How did you create the banner:
If you used DALLβ’E 3 or Midjourney, what prompt did you use?
I did not use AI but researched free creative license illustrations.
Thank you for not stealing from artists!!!
wowo