When reading the Nathan Bashaw’s interesting post on the making of Product Hunt one quote stood out for me:
In that sense, it actually helps that I’m not a very good engineer. I don’t fully grasp all the corners I’m cutting.
So in this case being a bad, as in inexperienced or unschooled, developer was a good thing? That is interesting.
To me this comes down to the focus you have while doing something. Are you focusing on making the best possible product or on crafting the best looking application architecture you can? The first doesn’t need to exclude the second, but sometimes having the perfect codebase may not be the most important thing.
The approach of quickly launching a product so that you can start getting real feedback from users has had many different labels, the currently most popular one being Lean Startup. Depending on which stage a project is at, obtaining learnings from a product might be more important than code quality. This goes for design as well, and most other parts of product development.
The idea is that at crucial points in the life of a product not worrying about your product being perfect, not shit either, but good enough to answer the questions you have about the product.
Questions like: Is it relevant to users? Is this the right direction to go in? Will users pay for this product? How much are they prepared to pay? Many of these questions can be fundamental to the success of a product, so it is important to get some answers as soon as possible.
Being a “bad” developer at that stage of a project to me means that you’re not excessively worrying about how to logically structure your code, what your test coverage is, or how it will scale in the future. All of those things are important considerations in the long run, but early on with a new or unknown concept it’s more important to know if you even have a viable product before taking it any further. First find out if you’re on the right track, then invest more and make it for real. A “bad” developer in this case is focusing on the product and how those vital questions can be answered as quickly as possible. They are taking shortcuts, compromising on performance, and just generally writing code that they probably should feel ashamed of, but they’re getting those product questions answered.
However, this is a very short sighted strategy, and it should be. A good approach to code quality and best practices are essential in digital product development today. It is a false economy to continuously de-prioritise practises like automated testing, refactoring, code reviews, pair programming, and so on with the idea that it saves time. You invest the time now to save time later, to help create a better and more sustainable product for the long run. This also differentiates the scenario of needing to answer important assumptions upfront from one where best practices are just being de-prioritised or ignored in the (false) interest of time or some other priority. Most projects have an element of pressure and limitations, based on reasonable or unreasonable circumstances, and cutting corners on quality based on deadlines or scope is a problem. All parts of the project needs to buy into what the ambition is in terms of code quality and best practice, you can then be pragmatic with the application of those as long as everyone understands the trade offs and potential for future problems caused by it, and work needed to fix it.
I don’t think there is a straight forward answer to when it’s OK to ignore best practices and when to start really caring about code quality during the start of a project or feature, it’s important not to let it get out of hand. If you’re starting a project where you don’t know exactly what the end product will be, you have a problem or opportunity that you’re creating a solution for, there will probably be a lot of product focused questions that will have higher priority than long term code quality at that time. As those questions get answered, and new ones come up, you will continusly be changing the product and the code base so having a good culture and knowledge of refactoring (what, when, and how to do it) is an essential part of transitioning your product and code base as you go. Working iteratively on a project means frequent refactoring, going over what you’ve already done and changing it for the better or in a different direction. As you answer those questions around the product, the concept, and the proposition, you will know if the project is worth while, and anything worth while doing is worth doing right.
Good developers know this and know when it’s important. Good product teams know when this is important. Good developers know when to be bad developers.