Previously at Uber, Skyscanner, Skype/Microsoft. I love to help people grow and share what I learned. I write longer articles on software engineering at blog.pragmaticengineer.com.
Nice article. I've observed two extremes of how to build things:
The hacking approach: do it as quickly as possible to get it working. This is fantastic for prototyping. However, if what you build will be part of a product that grows quickly, needs to be maintained and new developers work on the component, it will cause headaches and might result in needing to rewrite the code.
(Premature) optimizing. This is when, as building a new product or feature, the developer carefully plans on how to make it as extensible, reliable, performant as possible. Things take a lot longer to build. If we're talking about a new product, chances are, a lot of that work was done for nothing, as it might never get as high of a load or get extended as much as the developer planned.
I'd like to think that pragmatic developers sit somewhere in the middle, deciding on taking a hacking or more thorough approach based on the problem, the domain and other reality. For example, if you're building a financial application that goes live to people, you don't want to skip testing the business logic, no matter how much it would speed up shipping it. But if you're doing a throwaway prototype, going fast is fine, as long as everyone is clear that it's not going into production.
How do you find yourself adjusting your approach in different situations?
Much like choosing the right stack for the job, choosing your approach to building something should come from the job itself. Applications always have a few must-haves and those should largely impact your approach. I do think as a developer you can land closer to either side of that spectrum, and I know I'm more prone to working quickly and wouldn't therefore take jobs that require the more detailed/optimized approach.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article. I've observed two extremes of how to build things:
I'd like to think that pragmatic developers sit somewhere in the middle, deciding on taking a hacking or more thorough approach based on the problem, the domain and other reality. For example, if you're building a financial application that goes live to people, you don't want to skip testing the business logic, no matter how much it would speed up shipping it. But if you're doing a throwaway prototype, going fast is fine, as long as everyone is clear that it's not going into production.
How do you find yourself adjusting your approach in different situations?
Much like choosing the right stack for the job, choosing your approach to building something should come from the job itself. Applications always have a few must-haves and those should largely impact your approach. I do think as a developer you can land closer to either side of that spectrum, and I know I'm more prone to working quickly and wouldn't therefore take jobs that require the more detailed/optimized approach.