loading...
Cover image for The Worst Developer

The Worst Developer

stefandorresteijn profile image Stefan Dorresteijn ・2 min read

When I was getting started in Web Development, I was told it was good to be the most precise and detail-oriented you can possibly be. I worked with people who had much more technical knowledge of what goes on behind the scenes and I felt very confused. Not only was I not able to understand how everything worked, I also didn't feel a strong need to learn a good 80% of it. I wanted to build stuff, I didn't care whether the Fibonacci sequence was useful for authorization systems or that writing your own code was often much more efficient than using a library. I just wanted to make the things that excited me and I wanted to do it quickly, so I became a product developer.

I define a "Product Developer" as a developer who has a product-first mindset. Someone who prefers to focus on writing real functionality, as efficiently as possible. This doesn't mean that code quality and code efficiency aren't important; on the contrary, they become much more important. There's nothing that will slow you down as much as writing buggy code. However, a product developer won't spend hours or days trying to optimize a piece of code when a user won't actively notice the difference. They believe that they can write 80% of a product's functionality in 20% of the time.

Since I made the decision to focus on what I enjoyed, I found a real market for what I do. There are many small businesses and entrepreneurs who want to build a product or test an idea and just want it done as efficiently as possible. I learned many languages and tools, so I could apply the right one for the job. I'm not the best developer I know, I'm not even the best Ruby or Elixir developer I know, but I'm proficient at a whole set of language and tools that make it possible for me to build anything, and do so efficiently.

I've come a long way since I started all those years ago but the part of me that's generally disinterested in deep technical details still exists. However, instead of that making me feel insecure and worried that I'll never become a 10x developer, it gives me great confidence and clarity on who I am as a person and a developer. I guess what I want to say with this article is that it's fine not to be interested in optimizing the last little details of your code. It's fine to want to build MVPs all day. It doesn't make you a worse developer, it just means you're going to be working with/for a different market, and that's cool!

Discussion

pic
Editor guide
Collapse
stefandorresteijn profile image
Stefan Dorresteijn Author

I think there's a really fine line between being efficient and being bad. I try to toe that line by writing high quality code without focusing on the small details that could improve my code but would take hours of extra work to implement. It's cutting corners where it's possible and where it doesn't inhibit future development.

Collapse
bycedric profile image
Cedric van Putten

The way I see it, to be a specific type of developer (e.g. product or really technical), you have to learn multiple factions within the whole development.

A really technical developer can be a tech lead or CTO and help other developers grow with complex material.

Product developers may find it a bit more difficult when helping mid/sen developers with complex technical solutions, but they would be an awesome fit for product owner roles.

I think this article is a great example on how to mix "being a pure developer" with other parts of the whole process.

Collapse
gergelyorosz profile image
Gergely Orosz

Nice article. I've observed two extremes of how to build things:

  1. 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.
  2. (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?

Collapse
stefandorresteijn profile image
Stefan Dorresteijn Author

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.

Collapse
havarem profile image
André Jacques

For me, I called that the "do-er" mindset, people that do and don't "necessarily" passes hours abstracting something that they don't need (they will only if the need it). It enters very well in startups and the "lean" mindset where agility is key.

Collapse
openspeedtest profile image
OpenSpeedtest.com

"writing your own code was often much more efficient than using a library." True! ALWASE TRUE!

Collapse
codemouse92 profile image
Jason C. McDonald

Often. Not always.

Collapse
0n1r1k0 profile image
0n1r1k0

Well, I guess you're not alone (just joking) :)

Joke

Collapse
florinsith profile image
Collapse
florinsith profile image
Florin Anghel

I would like to belive this as well.

Collapse
jonathanray profile image
Jonathan Ray

Do you support/maintain the software you create? In my experience, a deeper understanding is beneficial, if not necessary, when you're responsible for the security, library updates/conflicts, scaling, logging, heisenbugs, etc.

Collapse
stefandorresteijn profile image
Stefan Dorresteijn Author

I do support/maintain the software I create, though often I'm only hired to make a proof of concept or MVP so there's much more work done on the base that I develop