A few days back a friend and I were reminiscing about how we started our careers and all the choices we made on the way. As I looked back, I realized how naive I was about so many things. I did a few things well, I did a lot of things wrong, I failed, and I learned. All very well - nothing unusual about it. After all:Only those who dare to fail greatly can ever achieve greatly. -- Robert KennedyBut there was one big glaring blunder which I should not have made. I insisted on learning only from my own mistakes. I disregarded good advice more often than was good for me. I'm good at learning from my own mistakes, I'm even better at learning from others. -- AnonymousI too should have been better at learning from other people's mistakes. I would have spend less time falling and picking myself up and more time building things.Despite having gone along different career paths, my friend and I agreed on one thing, which is - time and energy are the most important resources. They are also limited and scarce. Unfortunately the value of these resources is totally lost to us in our younger days. But as you grow in your work you'll realize that managing time and energy is what sets truly great performers from mediocre ones.

 

I'll discuss two very important tips which will help you reduce wastage of time and energy. These are things which most people learn the hard way, so I hope you'll appreciate them and put them into practice to build a better career.
Never get into arguments about the right way of doing something
I don't know how many hours I have spent arguing about the right way to do something. Almost every developer spends time in these arguments, but the really smart one's don't.Most of those arguments were about future proofing some feature. It went somewhat like this:

We need to do this because X, Y, and Z could change and we should be prepared for it.

Interestingly I have been on both sides of this argument. In my earlier years as the person who wanted to future proof everything, and in later years as the person who would cry YAGNI. There were times when future proofing turned out to be a huge waste of time and added more complexity than was required, but there were also times when future proofing did save a lot of effort eventually.So what's the right way? After fifteen years in the industry my answer is "neither - we just don't know". It's honestly hard to know in advance which requirements will change and which won't. There's no definite way of knowing if the investment in adding layers of abstraction will eventually pay off. But unfortunately this simple common knowledge does not deter programmers from spending hours at a stretch debating the right way. I have even seen entire meetings derailed by such discussions. So avoid endless arguments about the right way of doing something. They are toxic and should be avoided like the plague. Listen to everyone, understand their viewpoints, ask good questions, and finally take a decision based on what you feel is best. Use common sense, be modular, and avoid unnecessary complexity. 

 

However, I'd like to take this opportunity and suggest that you maintain a work journal. Make a note every time you take a decision, describing your specific reasons for taking it. Look back at your journal every few months and see which decisions turned out to be correct and which did not. Spend some time understanding your own thought process as well as the dynamics of  software development. Doing this consistently will help you improve your decision making skills without wasting your time debating the right way with colleagues. 
Prioritize your learning
Speaking of tons of things to do - part of it is tons of things to learn. In my first month at work I realized that everyone was infinitely smarter than me. Then I realized it would take me the next hundred years to learn what these people had learned in a decade. And then I found out that not everyone is really as smart as they seem. Sometimes people just used big words without really knowing what they meant. But some people did know a lot. They were really smart. So what was their secret?They were all intelligent. They were all hard working. They all had great focus. And they all new how to prioritize their learning. When you have a million things to learn and only 24 hours in a day, the first set of skills you have to cultivate are what to learn, and how much to learn.Let's begin with what to learn. When I started working I was overwhelmed with all the things I had to learn. I quickly realized that I could not possibly learn everything. Not even if I magically doubled my IQ. You need to be careful in selecting what to learn. If you select a range that's too narrow and you will become a pigeon-holed developer, and if you select a range that's too broad you will become a Jack of all and master of none. The definition of Just right IMO begins with the stack you are working with. This is where the bulk of your learning time should go. After that learn a little about competing stacks and a little about new innovations.However, this too is a pretty tall order and it's very easy to get lost in the forest if you don't plan the depth at which you are going to learn all these topics. An important rule here is - don't learn anything in-depth unless you need it immediately. So among all the topics of your programming stack learn only those topics which you use on a daily basis, in-depth, and learn the rest at a 201 level. Finally learn about competing stacks and new innovations at the 101 level.

 

I have spend a considerable time learning new stuff in the span of my career. What I have found is that if it takes 2 hours to learn something at the 101 level, it will take anywhere from 4 - 6 hours to learn it at the 201 level and about 2 days to learn the same topic in-depth. Another fact of learning is that the human brain forgets what it doesn't use. Now you'll realize why you should avoid learning things which you do not use regularly at a very deep level. You'll spend two days learning something only to forget it in a few weeks because you aren't going to use it. However, if you learn just the basic concepts, they will stay with you much longer, because basic concepts are more about connections than about practice and you would not have spend as much time.

 

Engineering is all about working in constraints. Managing your time well is also about managing constraints where you have to balance out various forces that want to take a slice of it from you. With a CS background, you'll do well to think of time management as an engineering problem where you have to manage and prioritize a limited resource among all the forces that need a part of it.