In his book, “The Passionate Programmer”, Chad Fowler explains how you likely aren’t putting enough thought into your career as a software developer.
Most people follow the common path of taking the first job they get accepted to out of school. This first job will require you to learn certain skills, technologies, and habits. And this will in turn lead you to a next job with similar requirements in the future, which will lead you to the next and so on. There isn’t really a plan or purpose to the career you end up with, you kind of just go with the flow leaving a large part of your career up to chance. Including the technologies you learn and the type of problems you’ll solve for the rest of your career.
This is the opposite of how most of us will approach a software project. We’ll put a lot of time and research into the different tools, design patterns, and different approaches we might want to use on a given project. We’ll constantly re-evaluate our progress during the project, and take a step back to re-think our approach if we’ve backed ourselves down a road that doesn’t seem right.
So why don’t we put this much thought into our career? We spend most of our life in at work, probably more than we spend at home with our families. Wouldn’t it make sense to put in some thought and create a plan for such an important part of our lives? Put in the research and consciously choose a career path based on what technologies we find interesting, the domain that excites us, and the people we’ll enjoy working with? Instead of just picking a job based on pay or convenience and leaving our career path up to chance?
Chad lays out a framework of steps to help us with this:
- Choose Your Market - Do research ahead of time before investing your best years and possibly locking yourself into a technology, domain knowledge, or team you can’t stand.
- Invest in Your Product - Now that you know what skills will be most valuable now and in the future. Improve your skills in these areas.
- Execute - You’ve got the skills, but it’s not worth much to your company by itself. Take advantage of your skills by delivering value to your company.
- Market - You’ve done great work that is valuable to your company, but it’s important to let people know about it.
- Repeat - Maintain your edge, repeat this cycle to stay on the top of your game and allow stay on a career path you actually want, instead of just going where it takes you.
Choose Your Market
Don’t let your career be decided by chance/coincidence. Using whatever technologies your first company out of school uses, working in whatever industry that company happens to be working in, and working with a team of people that just happened to do the same.
You wouldn’t do this with your programming right? Just jump right into developing features. You’d probably spend at least a little time talking to people first, getting some feedback on different options on how your product can help solve someones problems, getting a feel for what the core features should be. Maybe do some market research to see what else is out there, and where they fall short. Spend a little time thinking about what programming language, framework, or other libraries you might be able to leverage. If you’re really thorough you might even spend some time thinking through some high level design before starting.
And even if your plan turns out to be garbage, you’d be using an agile approach to be constantly evaluating your progress and making the conscious decisions to adjust as necessary. Just like a software project, putting in the time and effort into research and plan a career path will improve the chances you’ll end up with one you can be happy with.
The Technology your company uses will be the ones you’ll become an expert in. Do research, get a feel for what technologies are becoming obsolete vs which ones are trending upwards. Play around with different tools or build side projects to get a feel which frameworks you enjoy working with before you accept a job using a dying technology, or one that you hate working with.
The Business Domain you choose to work in is just as important, choose something you find interesting. Or is at least slightly related to a path you can get excited thinking about. For example, I used to do web development for the adult industry. The pay was amazing and the technical problems around scaling to millions of users, defending against fraud, and protecting peoples privacy were all very interesting. But becoming an expert in the adult industry just wasn’t something I was proud of. So I left for a job in the security industry.
Domain knowledge is very important in software development, but it’s often overlooked or overshadowed by pure technical ability. Think about this, it’s near impossible for a business person, with no technical background, to write a spec thorough and complete enough to address everything a developer needs to know. It’s just hard to understand how a computer thinks and what it needs to know to handle a situation if you’ve never programmed a computer before.
As a result, there are hundreds of tiny assumptions a developer will make when working with a spec. Unless they want to ask a million questions about every every edge case and scenario they can dream up. The more you understand the business domain, the better you can fill in those gaps, the easier you are to work with for the business team, the more valuable you are to the company.
The People and Teams I worked with is something I’d always taken for granted throughout my school and early career years. It wasn’t until I had my first bad experience with team members that I realized how important it was to my happiness, and thus how important it was to make a big part of my career plan.
Obviously you want to stay away from companies that have a negative culture. co-workers with ego, who don’t communicate, who are interested in politics are all red flags and things to stay away from. But one aspect of teams Chad really focuses on is how you should “always be the worst guy in every band you’re in.” Meaning if you’re too comfortable, and you’re not learning anything new, don’t be afraid to seek out opportunities or teams where you can learn new things.
If you’re around people better than you, you’ll pick up their habits, experience, attitudes, styles, you’ll learn new approaches, tools, and ideas. And you’ll improve to their level yourself.
“always be the worst guy in every band you’re in.”
If you stick around a team that’s below you, you’ll start to let go yourself, pick up the bad habits and lower your standards to match the codebase you all work in together. It’s like when you go back to you hometown to hang out with old high school friends. You’ve changed so much since high school, you have a professional career, got married, had kids, completely different person. But for some reason when you hang out with your old high school group, you just tend to revert to your old self again.
The one thought that crept into my mind as I read this was how it seemed way too scary to do this in practice. Find a team of highly skilled developers and ask if I can join their team? I would feel like a fraud, not worthy, holding the team back! I would hear in my head people thinking “who is this guy? what is he doing here, such a bother…”. I don’t have much advice other than just do it anyway. Chad admitted he felt this way, and I definitely feel this way, so if you also feel this way then it’s probably pretty common.
Invest in Your Product
Alright so you now you have a plan, you know what technologies you want to invest in, you’re in a domain you’re excited to be in for a long time, you’re on a team that’s right for you. So how do I start getting good? How can I build my skill and knowledge in order to get the career of my dreams? Chad’s got a ton of good suggestions, finding a mentor, reading code of well built projects, and of course practice, practice, practice! This is all good advice, and he goes into much more detail if you’re interested. But the advice that really stuck in my head was “Learn to Fish”
“give a man a fish; feed him for a day. Teach a man to fish; feed him for a lifetime” - Lao Tzu
Every time you come across something you don’t fully understand, but is critical to your workflow, your version control system, IDE, release tools, etc, write it down. Then pick something from that list and set aside time everyday to learn something new and useful about it. Ask yourself How does this work? Why does this have to happen? Experiment, build side projects using something you just learned until you’ve mastered it inside and out.
I love this because it’s something you can start right now, it doesn’t require to wait on anyone else other than yourself. And it’s something small you can do it everyday that will directly improve your skills until you stop.
So what are some examples in software development? Anything you need to ask others to help you with, any task that another team usually handles for you, or anything that is “magic” to you. For example:
- If you need a dev environment do you just ask the devOps team to set it up for you?
- Source control, do you know how it works
- Your framework or language features, do you know how they work? Or do you just use them but don’t know how they work?
It’s good to clarify all these things, as opposed to just have a half understanding of them. “The person who has a solid understanding of the business domain, language features, dev environment is much less likely to let certain mistakes slip through.”
And don’t just stop at the technical side of things, this goes for the business domain as well. Think about how much easier your job would be if the business guys understood your technical world. Imagine If they understood why this small feature would require a big design change, or if you could explain that a prototype which looks completely polished in a demo might take many more months to deploy to production. Without getting a blank look when you start explaining how it doesn’t yet work with nginx load balancing, mysql clusters, shared cache servers, and other extremely complicated environment setups we have. They think the exact same thing about you! every time you grumble about some tiny detail they want changed, but requires a ton of re-factoring, they are thinking “if only they understood how important this was.”
Pick up a trade magazine/blog/news website for your companies industry and read it regularly. You might not understand everything but just write down questions and keep at it. Your company will appreciate you’re trying to learn. Think about news, trends, issues, what is your industry/company struggling with right now.
Execute
Alright, so you’ve done the research, and you’ve put in the work. The next step is to execute, be a great employee, amazing team member, just as awesome at your job as you can be. This is different than just improving your skills and knowledge. It doesn’t matter to your employer how much knowledge you have in a specific domain, or how much experience you’ve built up in a certain technology. They care about the value you are adding to your business.
These might seem like the same things, but they aren’t. The skills and knowledge you have are just the tools you can use to bring that value, the tools you can use to contribute towards something the company actually wants. Think about it this way: There are hundreds of reasons you would be fired from a job, even if you were the most talented programmer in the office. Again, Chad’s got a lot great suggestions for how to be a great team member, but the one I want to focus on is how to deal with failure.
We all make mistakes, here are some of my own highlights:
- giving a co-worker wrong advice costing them hours of productivity
- creating new bugs in production
- designing your team into a corner
- Crashed production
- Led failed/cancelled projects
- Mis spoken in the worst possible way making the CTO dislike me!
Whether technical, communication, or management mistakes, follow these rules:
- Raise the issue as early as you know about it – don’t try to hide it, just like in software development, the earlier a bug is caught, the cheaper it is to fix it
- Take the blame – even if it’s not wholly your fault, the goal is to move past the mistake, playing the blame game just generates more conversations and prolongs the whole issue
- Offer a solution – or if you don’t have one, have a plan for finding one
- Ask for help – people will look at you better if you maintain a healthy attitude towards the problem. Don’t let pride get in the way
Think about the last time a waiter took too long to bring your dish. Wouldn’t you be happy if the waiter apologized as soon as he recognized it was going t o be late, took full responsibility, genuine apology and move on. Or would you rather the waiter hope you don’t notice it and just ignore it/avoid you, and then blame it on everyone else in the kitchen.
Now the one thing you should absolutely NOT do is PANIC! In sports, the best players never panic. In television the heroes never panic. Panic never helps, but it’s kind of like saying don’t worry, just be happy, but how? Try to keep things in perspective. After all the disasters I’ve been through, has any of them had a lasting negative impact on my career? I can honestly say no.
Another way to put it in perspective, imagine your parents doing something on the computer, and they can’t get it to do what they want. So they get frustrated and just start blindly clicking any and all settings buttons then can find, before finally giving up and calling you. You would never do that right? Because you know all that clicking just makes things 10x worse. You know if you were in that situation, you would read the error messages, google solutions, read the buttons and prompts before clicking and then figure out whats wrong.
Well, the difference is that your parents aren’t in their comfort zone, so it’s easier to panic. Just like you aren’t in your comfort zone when you mess up at work. Think about how much better it would be for you to not panic and make things worse, but instead carefully and calmly work it out, just like you would if your parents had a computer problem.
One final suggestion Chad made is a way to avoid failure all together. By just saying “No”.
“the quickest path to missing your commitments is to make commitments that you know you can’t meet”
We want to say yes because we want to please our boss. But it actually does the opposite. Saying yes and not meeting the deadline will make your boss way more mad. The more you aren’t able to fulfill a commitment, the less he’ll trust you, and the more he’ll start to second guess you. Until eventually, your commitment won’t mean anything at all.
The reason your boss hates this so much is because when you tell him you can do something, he is also telling his boss what his team will be able to deliver. And when you fail to deliver to your boss, he fails to deliver to his. Except his boss is much higher up, you might be making your boss look like a failure in front of the CTO!
Saying no is good because that means when you say yes it actually means something. Saying “I don’t know” is also good in the right circumstances. Just don’t go overboard. If you’re not sure, something like “I’m not sure but I want to give it a try” is good too.
Final Thoughts
And that’s about it, Research, Invest, Execute, Market, Repeat. But it was basically just saying that you need to let people know when you do well. Do this and you’re well on your way to working in a career you planned for yourself, instead of working in a career you landed in by chance. I didn’t really get to talk about the “market” or “repeat” parts of the cycle. The “market” chapters were pretty self explanatory, let people know about your good work. But the “repeat” portion was more interesting to me so I wanted to mention it briefly here.
Once you’ve done the research, put in the work, and have had good success in your career, it isn’t the time to stop learning. In fact it’s the opposite, it’s time to repeat the cycle before it’s too late.
Technology moves incredibly fast. Just because you are skilled at a certain thing, and being skilled at that thing is what’s given you so much success in your career, doesn’t mean you shouldn’t constantly be looking around for better things. There was a time when jQuery was the latest and greatest. Can you imaging how hard it would be to find a job if that was your top selling point now?
It’s an easy trap to fall into because we know what has worked and we keep doing it. Or we make a goal and we just keep going for it without paying attention to what’s around. Keep repeating the cycle, research new technologies, invest in the ones you think are worthy, and execute in your job so you’re always moving towards the career you want and planned for.
Buy This Book on Amazon