It’s a wonderful time to be a software developer. The opportunities are abundant and the languages, frameworks, and tooling we use to do our jobs are amazing thanks in large part to our collaborative efforts in the open source world.
One negative aspect I see of this proliferation of excellent libraries and frameworks is the consumer mindset it can bring forth in developers. I think we all struggle with it, and my own struggles in this area are what inspired me to write this post.
This post is not a comment on the debate of whether software developers should be called "engineers" or not. The term "engineer" was chosen simply because of the contrast with "user".
The point of this post is not to divide all developers into either “engineer” or “user”. I believe everyone experiences moments on each side. The point is to recognize when we’re acting like users, and to change to the engineer mindset instead.
I also tried to keep the technology of this post as general as possible. I believe these characteristics apply to small things like languages, frameworks, and databases all the way up to larger concepts such as patterns and architectures.
User: Follows the trends and always picks their technology stack based on what’s hot and popular.
Engineer: Looks at all the factors when choosing a stack, and isn’t afraid to pick something old or uncool.
This is one I find myself struggling with the most. Take JavaScript for example. We all know there’s a new hot framework or trend emerging every day. This is great because we’re driving the web forward, but we also need to be careful to not just simply be a trend follower.
One thing I have to remind myself of all the time is that a great developer or team can build a tremendous product using any technology — new or old. There are teams of developers right now that are killing it with ASP.NET Web Forms. They’re delivering value to their business because their teamwork, process, and collective skill has transcended the need to use the latest and greatest.
When choosing a stack, engineers consider all the factors involved. That includes business constraints, existing systems, team experience, and many others. They’re not afraid to pick a stack that is old or gets a lot of hate online. At the end of the day, the most important objective to them is delivering value. Does the average user care if their application was created using .NET/Java/Node or AngularJS/React/Ember? Not even a little bit. They care about the application’s functionality and reliability. Both of which can be achieved in any stack.
User: Gains experience in one language or stack and uses it to solve every problem that comes their way.
Engineer: Constantly seeks to broaden their horizons so that they can pick the best tool for the job.
At first glance, this characteristic might seem like it conflicts with the first. The point I’m trying to get across with this characteristic is similar to the hammer analogy. A user discovers or gains experience using a specific technology, and soon every problem looks like the nail that technology was built to solve.
Users get immersed in one technology or vendor, and don’t keep up with competing products and ideas. They are loyal to this vendor like they are with any other consumer product or brand. They even have holy wars with other developers about why their chosen stack is the best.
Engineers know that there will never be an end all be all technology suitable for all problems they encounter. They prefer to stay technology and vendor agnostic. This allows them to experiment and learn about the strengths and weaknesses of new technology, and apply that knowledge when it comes time to pick a technology for a production project.
User: Contributes nothing back to the community of the projects they rely on. They may encounter problems, and build elegant solutions, but they never share their knowledge back to make the project stronger.
Engineer: Contributes back to the projects they on which rely in the form of code, documentation, blog posts, Stack Overflow answers, etc.
After thinking about this characteristic for awhile, I’ve decided there’s an underlying reason the user inside us all doesn’t contribute knowledge back to the community as much as we should. The following is how a user solves problems:
Encounter problem.
Google frantically for a solution.
Apply first solution found from Stack Overflow, random blog, or documentation that looks like it will work.
Verify the solution has fixed the problem.
Repeat.
How an engineer solves problems:
Encounter problem.
Find root cause of the problem.
Research possible solutions (may involve Googling), and consider implications.
Apply the best solution.
Share experiences.
Repeat.
As users, we want to quickly slap together a solution, and move on. We think this is the best route because thoroughly researching an issue and taking the time to develop a holistic solution takes time. However, we lose out on the long term advantages of a deeper understanding of the problem — not only for ourselves but also for others who might encounter the same issue.
Thanks for reading! I hope some of this post resonated with you and your experiences. I’d love to hear your feedback and thoughts.