51–60 of 274 posts
I prefer the quote that goes "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
Sorry next developer, I'm on a tight deadline, used to love this craft, now I just do what the product people tell me to get a nice paycheck.
Yep. Yesterday I ran into a job opening asking for "Java developer who delivers 3x faster than the other developers" in one of the bullet points. It's such a weird point to emphasize that you want speed with no concern to trade-offs, and the maintainability and scalability of the codebase will be the first victims sooner or later.
Years ago a wise man told me "The compiler is not your customer. The next person who maintains this code is your customer. It might be you."
In my opinion, good code is like a Brita filter. It does its job, will one day need to be replaced, and it should be easy to replace. More importantly: metaphors are not a healthy way to understand an idea. Ideas are more nuanced than a metaphor could possibly account for. Abstaining from metaphors might not make for a catchy headline though.
Little pushback here - metaphors are great tool to understand something, and can convey some meaning more efficiently than other means. But "the map is not the territory"!
In my opinion, good code is like a Brita filter. It does its job, will one day need to be replaced, and it should be easy to replace. More importantly: metaphors are not a healthy way to understand an idea. Ideas are more nuanced than a metaphor could possibly account for. Abstaining from metaphors might not make for a catchy headline though.
Metaphors are also ways of communicating ideas. A good metaphor is as simple or as complicated as it needs to be in illustrating a new concept
Example: Array of items as a shopping cart: how do you efficiently remove an item from the array (as you can from a shopping cart)?
As a codebase outlives its best-practices, do you stick with them and extend with those same anti-patterns or do you implement new things with a different mindset than the rest of the code?
-- If you break with tradition then you are making it harder to understand the codebase as a whole.
eg: why do we have a mix of procedural/OO/functional/... methodologies with spaghetti code at the core?
-- If you refactor everything then you are definitely breaking something.
eg: you have a 10M+ line java codebase with transformations bringing you into the 2020s from coders who originally knew C and Java 1.4.
-- If you keep with tradition then are you writing the best code possible?
eg: would you willingly use goto of some variant in new code if you jumped into a Cobol 74 codebase?
Reminds me of the Damian Conway quote "Documentation is a love letter that you write to your future self"
Good code is not like art, such as good books or paintings. No matter the quality of your code, if the product or service is not a good market fit. It will be retired. No one will stumble upon it or pick it up after it's gone. Knowing this, the only reason for putting effort into it is to make it easier for myself.
The times you appreciate it are actually when you open something and it’s nice and easy to change and you realise you were the one who wrote it. But real developer happiness comes when you have the same experience and someone else wrote it.
I don't really care that much about the developer, and care a lot more about the users of my product, especially since that developer is usually me.
If I'm unsure of the value I'm adding, or if the ability to do something is greater than its quality, I will take shortcuts if needed.
If the codepath is critical, or if doing so is dangerous, I will take my time on the quality and the foolproofness. I will be pertinacious in this mindset, and if managers try to rush me, I will remind them of the consequences of failure and log everything.
I've seen too many developers (myself included) spending weeks and months on perfecting something that's never used, or barely used. The latter issue of not spending enough time is a lot more rare, but does happen.