I like the idea of readability-lite for smaller companies.
When you have very few in the company, i.e. < 5 developers, you usually don't have time to spend on anything else than the absolute necessities. I'm starting in a company very soon with 2 software engineers and 2 marketing people in total. Reasonable readability goals with a valid…
I like the idea of readability-lite for smaller companies.
When you have very few in the company, i.e. < 5 developers, you usually don't have time to spend on anything else than the absolute necessities. I'm starting in a company very soon with 2 software engineers and 2 marketing people in total. Reasonable readability goals with a validity check from a collegue is then sufficient I think. But most important is of course that you solve the problem. Usually that transfers to writing the proper unit or integration tests.
After all if the code looks ace and everyone loves to read it, but it won't solve the problem, it's just a waste of time :-)
I like the idea of readability-lite for smaller companies.
When you have very few in the company, i.e. < 5 developers, you usually don't have time to spend on anything else than the absolute necessities. I'm starting in a company very soon with 2 software engineers and 2 marketing people in total. Reasonable readability goals with a validity check from a collegue is then sufficient I think. But most important is of course that you solve the problem. Usually that transfers to writing the proper unit or integration tests.
After all if the code looks ace and everyone loves to read it, but it won't solve the problem, it's just a waste of time :-)
I agree! Readability-lite is a great idea, but readability for the sake of "nice looking code" is pointless.
You make a great point of making sure the problem is solved. After all, we're hired to solve problems, not just write code :)
Just to be clear: The article was great. I wouldn't bother to comment otherwise ;-)