It happened again yesterday.
I was completely focused on some code when my manager jumped out of nowhere and started shouting: "The cyclomatic com...
For further actions, you may consider blocking this person and/or reporting abuse
In a more serious tone. I think we always have to trade off quality of code vs quality of app + speed of delivery.
One month you release something, other month you fix stuff and organize your code, refactor here and there.
We should care about best practices and patterns and wonderful stuff but what really matters is that we are able to deliver (not necessarily on time), be able to do future changes without being a PITA AND be able to work in a project we care and feel proud of because of the previous reasons.
If you deliver but the codebase is always a mess, one day or another you'll be exhausted and frustrated.
If you do not deliver but your codebase is a wonderland, what's the value if no one is using it?
It's better to deliver and enjoy. It might be a mess today but if you can fix it tomorrow, it'll be great.
As somebody else summarised: "clean code is not that clean".
BTW, I loved your "Pintor de brocha gorda" image 🤣
A good manager should be able to either provide technical guidance or at least ensure that it's coming from somewhere.
I've seen teams complain that management rushed them. So management stopped rushing them. The quality of the code didn't change at all. Not even a little bit. The developers had no idea what to change, and neither did management.
From my experience teams achieve better results when they have complete responsibility over the piece which they produce, from gathering requirements to post-go-live maintenance, an can make decisions on their own. With all respect for managers, very often I saw ones who do more harm than good for the projects through micromanagement. Team also work better knowing the long-term vision and plan and don't jump from project to project every quarter but have enough time to learn the project. I know companies which work in silos where no team really owns the product, one team works on features, other work on bugfixing yet another do deployment. When work is spread like that no one really feels the impact of doing good work from the very beginning till the end and no one feels responsible for failures. In most cases like that I saw a poorly designed solution, discouraged employees and high turnover. Personally I prefer to work in small self-organizing independent teams but this works when at least a few members have experience, I definitely would not risk it with all junior devs in a team, even though I saw some excellent junior teams in action, but general experience is that juniors have too much fantasy to experiment with technologies and tools ;) while seniors tend to find a good balance and prefer battle tested solutions.
Wow! Awesome awesome write-up! I was hoping to write something like this in some time, but as I began to read your remarks, I was saying to myself, "this sounds like some ideas from Sandi Metz"! And bam! You hit me with a remark by her. You pretty much nailed it! It brings to light that sometimes the overuse of DRY paints us into a corner where we don't yet know the right abstraction. Man, it'd be cool to work with someone like you. And funnily enough, you write Clojure, so I take it that you're also a fan of Rich Hickey's talks, like "Simple Made Easy" :D
Rich has been a huge influence!
Quality writing. Thanks for sharing.
Typo to fix Dan: Highsight -> Hindsight :)
Well said though!
Same "typo" three times.
Thanks for the correction!
Too true, and very well written.
I've made some similar points before...
Clean, DRY, SOLID Spaghetti
Jason C. McDonald ・ Jul 24 '18 ・ 9 min read
I had more than a laugh readying it. Very much in agreement with all of it!
Thanks for sharing!
Awesome read.
Great post! I really like the closing sentence.
Likely outside of the scope of this article, but I've begun to find "the most effective" way, for me, being guided by Domain-Driven Design for anything "non-trivial". Have you used it or other patterns to help guide you?
I have the feeling that my last 15 years of career, I have mostly written "trivial" integrations, and for this I have found youtube.com/watch?v=iLMiPhYVG8w to be the most effective.
Nice sentence! A painter is not proud of his brush; he/she is proud of the art they create with it.
"Why" we follow best practices is an excellent point. We should always be reflecting on whether a specific technique or process is useful for us.
I personally don't follow best practices or read up on code design principles or whatnot. I won't remember them, and most of the time I find that I already practice them even if I can't put a name on it. If you ask me what SOLID or DRY means I likely will stumble.
For example, only a few years into my coding did someone look at my code and say "hey that's some nice dependency inversion" and I had no idea what he was talking about until he explained the concept and I was like "oh, is that what people call it". To me it was just something I thought of after getting bitten by new feature requests time and time again and then it just sort of worked out even if it was rough and didn't follow "standard practice" that people might have learned from somewhere.
Most of the time I'm just coding to spec and trying to push out a prototype in matter of minutes or hours so that I can get a greenlight from the client, and any abstractions and other design considerations are based on my own experience of whether it's useful or not. Now, I sometimes do read up on patterns and best practices because I think I have enough experience to be able to say whether it's something I want to adopt.
We should stop saying “best practices”. They are just practices, that is some contexts they are the best to get the job done. In other contexts, they are not.
Always reminded of this image whenever threads like this come up...
Lol
Great post
Great post 👏
Managers should be coders. I don't believe there are exceptions to that rule, at least I've never seen a good exception.
I thinks that works up to some team size.
But a manager’s job is different than a developer, so I would not expect a manager to be the best developer, as she should be learning management skills. That is why “good managers ... also know their limits and wisely stay away from the code.”
You should come here, compare the project made by the guy who understood clean code and the one who doesn't... my legs shiver when I have to change the second one.