Nowadays I see people going crazy about automation. Everything must be in Docker containers, If it’s not in docker, I ain’t touch it.
Every task must be performed on the CI server, every repetitive task must be converted to a script, nothing in the MVP can the back office do manually. People are praised when they claim: “automate everything”!
I am on the very opposite side. I think automation generally isn’t worth it. It can be harmful to your project and see the trend of “automate everything” kinda crazy. Let me explain why.
This post was originally posted on medium. Here I paste it and give it a fresh look in a few places.
Was anyone else ever under impression that principles of software development are a mess?
In one of my previous posts – YAGNI is king – I advocated the idea of not anticipating future when it comes to developing features.
I got some feedback that I want to discuss: YAGNI applies to features, not design. When designing software, you have to anticipate the future. Therefore, sometimes you have to give up on YAGNI if you want a good design.
In other words: on a pull request, when you see an extra piece of code, don’t automatically assume it violates YAGNI. Maybe it’s for design purposes.
I take the point, but also have to add something on my defense.
In the previous post, you could learn why visibility is extremely important in IT. If you’re still missing ideas on how to achieve better visibility, read this post. I present you 9 concepts of how you can increase visibility in a typical programming project.
Have you wondered how to effectively communicate in IT?
Make it visible. Extremely visible.
Professional, technical communication is one of my soft spots in software development. It’s useful in situations like code review, status update, standups, meetings, backlog refinement…
Check this post if you’re looking for tips on how to improve your everyday communication.
Check out also part 1 – 10 communication quick wins for developers.
The term “full stack devs” seems to be reserved to the web only. What’s worse, as a web dev I’ve always felt pressure to know well both frontend and backend.
On the other hand, I’ve worked with many mobile devs, none of whom I would call a full stack. Typical mobile dev needs another dev (backend dev) to create a full-fledged app.
I still don’t understand why. Let me debunk a few typical answers that I’ve heard but I don’t find true.
When it comes to adding complexity to the code, I generally see two schools of programming:
- Top-down: start with abstractions, then write implementations for it.
- Bottom-up: write down the whole implementation, then make abstractions out of it.
This post advicates the second school.
My very first post on this blog was about swimming. Welcome, 2019, it couldn’t be different – let’s make a summary of my swimming habit!
A list of questions and topics to cover on your next kick-off + best practices on some of them.