This post was first published on CoderHood as Best Strategies To Invest Your Engineering Time Wisely. CoderHood is a blog dedicated to the human dimension of software engineering.

When I started coding in 1984, there weren't many choices of languages and technologies. Basic, C and Pascal were the main ones. Only a few books on the topic were available, and the internet didn't exist. With such a limited choice, it wasn't difficult to decide how to spend my learning time to become a software developer. Distractions were not a problem, and networking wasn't much of an option either.

Over the years things changed dramatically. Today you have an incredible array of options and information to choose from. Deciding where to spend your time can be daunting. Should you become a generalist, and know a little bit of everything? Or a specialist, and know one thing well? Also, should you learn to write code at all? Are you trying to start a business, or are you trying to learn to code? What are your goals?

In this article, I am going to explore the concept of "investing your time wisely," both from a business standpoint and from an engineering standpoint.

On Goals

The answer mostly depends on what you are trying to achieve. Is learning to build software your goal? Or is your aim to create a business, website or a piece of software to release to the market? In other words, is becoming an engineer (or a better engineer) what you are trying to do? Or are you trying to start a technology business? Think about it; the two things are very different.

If what you are trying to do is starting a technology business, you should consider your options. The engineering path might not be the fastest and easiest way to achieve your goals.

Mark Zuckerberg learned to write code first and built Facebook later. Bill Gates followed a similar path, starting as a developer early and creating Microsoft later. Those are examples of engineering-centric entrepreneurs, who learned the craft of building software and created businesses around their creations.

Others, like Steve Jobs, were never engineers, but they created terrific companies and products developing a different set of skills. They had ideas and found technical partners to realize them.

Let me give you a non-tech example of the difference.

Getting a Desk

Imagine that you need a desk for your new office. You know how big it needs to be based on the space you have available, and you know that you want three drawers on the left, just like your old desk. The vision is pretty clear, and there are many paths to realize it.

Many Options With Different Tradeoffs

You have many options to achieve your vision. Each of them requires different levels and forms of investment of your time and money.

OPTION 1 -- Buy It Somewhere

One of the options is to buy it in a store; this is a simple solution because it gives you what you need quickly, cheaply and with minimum work.

All you'd have to do is to browse catalogs and find the closest store to pick it up. If the desk is too big for your car, you'll have to order it online or rent a truck. Renting a truck adds a complication. You'd have to go to a vehicle rental place, get a truck, drive the truck to the store, buy the desk, put it in the truck, drop it off at your office, return the truck to the rental place, go back to the office and put the desk together.

If you buy the desk this way, the quality and the cost is well understood from the beginning. You can see the desk before buying it, you can touch it, sit in front of it, and you know the pros and cons of purchasing stuff from a particular store. You can also read reviews of that item, and return it if you are not satisfied.

OPTION 2 -- Order it Custom Made

Alternatively, you could order the desk from a commercial furniture maker. This option gives you the opportunity to design it to your exact specifications.

To go in this direction, you have to draw a plan of what you want, including all the measures, materials and details. Then, you have to negotiate with the vendor the type and quality of the materials, timeframe, and cost. When the piece is ready, you have to arrange delivery to your office.

The quality of the result depends on the selections you make, your negotiation skills and how much money you have in the budget. In general, this is not a great option if you just want one desk unless you need an exceptional piece.

OPTION 3 -- Build It

Another option is to build it yourself. If you want the desk made out of wood, and if you already have tools and expertise with woodworking, you could save a bunch of time and money.

However, if you don't know anything about woodworking, getting started is lengthy and expensive. You have to empty your garage to create a woodshop, take woodworking classes, buy the tools and practice on a few scraps before attempting to build the desk. A desk might be a problematic starting project, so you might have to build simpler pieces first.

The result could be great or terrible or anything in between. It depends on your level of expertise, dedication, talent, time invested and quality of the tools you purchased.

OPTION 4 -- Setup Up Shop

Finally, you could decide to hire a bunch of woodworkers, set up shop and get them to make your desk. That would require a great initial investment of time and money, and it would make sense only if you intend to build much more than just this one desk.

In return, you'd get a desk to your exact specifications, and any piece of furniture you'd like to build in the future. If you make a lot of it, the price of each piece will go down considerably over time.

Unless you are wealthy, this option is economically viable only if you want to enter the furniture business. That is a much different problem to solve than just getting a piece for your office, but it is an option nonetheless.

Choices in Tech

Tech entrepreneurs face similar problems and choices when they need to materialize a piece of software. A project starts with a goal and several possible approaches, each of them with different pros and cons:

1. Use a product that is already available. This choice gives you limited but apparent options concerning selection, price, and quality. In most cases going in this direction is the only cost-effective solution.
2. Hire an engineering shop to build it for you. This choice opens many possibilities, but it is going to take time and effort. You have to find a vendor that you trust, describe precisely what you want and how you want it done, negotiate a price and the terms, and guide the vendor throughout the process to ensure they are doing the right thing. You might have to integrate the result with an existing system, which can be a complicated and expensive thing to do.
3. Build it yourself. This choice is excellent if you are an engineer, already know a viable technology to build it, and have experience building similar applications. Otherwise, this can be a very slow and expensive path to take. You have to learn whatever technology you choose to use and acquire the necessary software tools. Then you'd have to build the software, and deal with the fact that you won't get it quite right if you don't have any expertise with the particular problem and technology. Additionally, you need to be prepared to maintain it for its lifetime, which is a long-term cost.
4. Hire a team of people to build it for you. In this case, you need to know how to hire engineers, train and organize the group to develop the product you envision and manage the team. In other words, you need to start a development shop; this is an economically viable solution only if you are starting or running a business.

Watch Out For Common Fallacies

When evaluating options, you should watch out for common fallacies that are going to lead you astray. Assessing how to invest your time is one of the few variables in your complete control; making smart decisions is the difference between wasting time and working on what matter most.

The "I Build It Because I Can" Fallacy

Software Engineers know how to build software; that's what they do. When they are faced with a problem they don't know how to solve, they work hard to figure it out. Either way, their preference is to create solutions from scratch and to build them exactly the way they like it.

While this is understandable, building software from scratch is not always the most cost-effective solution. It makes sense only in the following situations:

• For practice, to learn a specific set of skills. While it is a good thing for an engineer to learn new things, it is essential to differentiate between practice projects and real projects. I advise to not start an important project as a practice one. If you are convinced that a technology you are not familiar with is the right choice, practice on a small scale experiment first.
• If what you need doesn't exist yet, and the value you'll get out of it justifies the cost of building it and maintaining it.
• If what you need exists in the market, but it is too expensive to buy or otherwise difficult to get.
• If the software you need is at the core of your business, and building it by yourself increases the intellectual property of your company.

In all other cases, organizations are better off by acquiring software that is readily available.

The "Once I Built It, I Have It" Fallacy

It is true that once you build a piece of software, you have it and own it. It would be nice if, at that point, you could just sell it and use it forever with no additional investment. However, software is never "done." Once you built it, to keep it alive, you have to maintain it.

If you stop maintaining it, eventually it stops working because everything else around it changes. Operating systems evolve, systems you integrate with change, the internet changes. Everything changes. The software you invested on will eventually start having problems, and sooner or later it will stop working.

Building software is like planting plants in your garden. The more plants you have, the more maintenance you are going to have to do every year. The cost increases, and eventually, it takes all of your time.

If you start a company with three developers, they will be busy building new stuff all the time for a little while. Eventually, all of their time will be consumed maintaining what they created. That's when you know you need to expand the team and grow. The more you build, the more you need to support. Accumulating software that you are responsible for taking care of requires a growing group of individuals and an ever-increasing maintenance cost. That's why, these days, many software companies moved to a SAAS model, where a customer, to get the benefits of supported software, continues paying a fee every year.

The "I Must Learn Everything" Fallacy

There are not enough hours in a day, days in a week, weeks in a month and months in a year to learn all the cool stuff that you could learn. There are too many technologies, languages, frameworks, resources, tutorials, tricks, trends, algorithms, opinions to consider and problems to solve.

Engineers are like curious people walking through a bookstore full of exciting books. Which one to read? How to choose where to invest time? The possibilities for distraction are endless.

There are many answers to those questions, but learning everything is not a viable one. If you had to choose between two undesirable extremes, it'd be better to be a master of one language and framework rather than to know a little bit of everything. That said, extremes are rarely good examples, and reality is more nuanced than that.

Building Software For Living, Where to Invest Your Time

If you decided that you want to be a software builder, you should know that learning never ends, no matter how you approach it. So, what is the best way to invest your time in the lifelong learning process that is ahead of you?

On Breadth (Generalist) vs. Depth (Specialist)

Let's do an intellectual exercise. Let's imagine that two developers, a generalist (Gus) and a specialist (Sally), are asked to build the same system that requires both front-end and back-end work.

Gus knows Ruby on Rails, Python Django, and Java Spring. He has never mastered any of those technologies, but he knows his way around them. Sally knows only Python and Django, but she knows them well.

Who is better off?

In this situation, at the very beginning of the project, Gus has an advantage because he can make an informed decision between several languages and frameworks. Let's say that he choose Java and Spring.

On the other hand, Sally has only one option in her toolbox, and she is going to choose Python. Once the initial selection is made, Gus starts coding with the skills of a mid-level Java developer and Sally starts coding with the capabilities of an expert Python developer.

Even if Gus is right to think that Java is a better choice for the project, the chances are that Sally is going to generate quicker results. She is at home with Python and Django, and she has no problems hitting the ground running.

Things are not that simple, however. After a while, Gus's experience with multiple technologies pays off and gives him inspiration for better designs and solutions. He might not understand Spring as much as Sally understands Django, but it is not difficult to pick up what he needs as he goes.

So, the question stands: Who is better off? Gus or Sally? The answer is: It depends on how you measure success.

• Gus makes better technology decisions; that is better for the long-term of the business.
• Sally hits the ground running, which is better in the short-term.
• Gus moves slowly at the beginning of the project because he needs time to learn to use the technology he selected.
• Sally moves quickly from the very start and builds a system that follows best practices in a particular ecosystem.
• Gus applies his experience with other technologies to design more robust solutions and come up with creative ways of resolving problems.
• Toward the middle of the project, Sally starts experiencing limitations of the technology she selected. Performance, lack of specific features and weaknesses of the development tools get in her way.
• Gus instead tends to accelerate. His early technology decisions pay-off; as a result, he hits fewer issues.
• Toward the end of the project, integration to existing systems requires Sally to branch out her comfort zone and work with some other technology she is not familiar with.
• Gus has no issues with the integration with existing systems. He is familiar with the technologies involved, and breezes through that phase without problems.
• After the project is finished, the work that Sally did follows best Python practices, and other Python developers easily maintain it. However, the integration with existing systems is buggy and causes problems. Additionally, her lack of breadth and experience causes her code to be less efficient than it could be.
• Gus code is not best of breed Java and Spring; he learned much of it by working on the project itself. While his work functions, it is not as easily maintainable as it could be. However, his integration with existing systems works very well from day one.

Finding a Balance Between Being a Specialist and Being a Generalist

The story of Gus and Sally is just an example of a situation where it is difficult to say if Gus, the generalist, or Sally, the Specialist, were more successful. There are pros and cons, and a final verdict would require more details. Since I made up the circumstances, I could easily sway the example in either direction.

In practice, you don't have to choose to be a pure generalist like Gus, who is not a master of any technology, or an absolute specialist like Sally, who knows only one. Either choice would be limiting.

You Need Both Breadth and Depth

Instead, I recommend to master several different technologies and play with many others. During your career, you should go deep in one technology, and become an expert in it. Then, you should switch and go deep in something else. When I say, "Become an expert," I mean that you should focus on that technology for at least two or three years and build non-trivial products using it.

For example, you could spend a few years working on Java and Java frameworks. Then, you could switch to Ruby on Rails, and go deep in that area. A few years later, you could move to Python, and dig deep. During that time, you should also superficially "play" with other technologies, just to become vaguely familiar with them, but without investing a lot of time in them.

In my career, I have been an "expert" in several languages: Pascal, Basic, Assembly 80×88, Java, SQL, C, C++, Ruby on Rails. I've also played with many other languages and technologies, but I never felt like I reached mastery. Examples are Python, PHP, Perl, Prolog, JavaScript, and a few others.

When you reach mastery of a technology and switch to something else, you'll tend to become rusty on the technology you turned away from. Don't worry about it. It is not difficult to get back to it if you need to, and you never lose all you learned. The concepts and problem-solving skills will stay with you forever. They become part of who you are, and they'll help you in seemingly unrelated situations.

Technologies do change over time, so if you go back on something you abandoned, you might have to catch up on what you missed. However, the knowledge and experience you acquire going deep many times in different areas will make you a stronger developer. With each deep dive, you'll solidify your problem-solving skills, you'll learn new patterns and techniques, and it will move you to the next level of your technical growth.

On the other hand, if you stick with one technology forever, you'll never go past that level. You'll become what I call a "Senior Junior," which is someone with many years of experience in a limited area of knowledge. This is often referred to as being "pigeonholed," and it is not a great way to grow.

Conclusions

• If you want to start a business, consider buying software already made or getting somebody to build it for you.
• If you choose to be an engineer and build software, learn by going very deep over and over again. Focus most of your time on one technology at the time. Spend a few years in each deep-dive, and master it. Don't worry about forgetting what you've learned in the past. What matters will stay with you.
• At the same time, explore and play on a side with various other technologies to avoid becoming isolated.

If you enjoyed this article, keep in touch!

• Find all my posts on CoderHood.
• Join my professional network on LinkedIn.
• Follow me on Twitter.
• Join my Facebook page.
• And finally, follow me here on dev.to!