You will encounter good managers and bad managers in your career. I’ve found that one common thread for all managers is that they are busy. Busy with meetings, busy with coordination with other teams or parts of the business, busy putting out fires, busy with helping team members. Busy busy busy.
They also will likely be responsible for your career. Promotions, compensation increases, title changes. A good manager will want you to be challenged and grow and learn.
The only person who really cares about your career is you.
You can help your manager help you by helping them know what you do. Sometimes this feels like an undue burden. Surely your manager can keep track of what you’ve accomplished on their team. And some do know some of the stuff you’ve done, some time.
But what you want is to help them know everything that you’ve done that you’re proud of. This helps them understand what a great team member you are, and also gives them ammunition to fight for resources (money, projects) that you deserve.
One place to put this information is in your LinkedIn profile (more about my opinion on LinkedIn). Of course, make sure you don’t reveal any company secrets (projects, launches, technologies) in this.
Another alternative is an internal brag document. Julia Evans has written a great post on writing one. This outlines one way you can help your manager (and yourself) keep track of all the great work you’ve done. It can be far more detailed since it is internal and not limited in length.
It’s not just limited to project accomplishments. You can build a bigger story. From the post:
In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?
I haven’t written one of these (although you could consider my blog somewhat of a brag document, I suppose. Yet another reason to start a blog). But having some kind of record of your accomplishments that you can share with your manager will help them help you.
I remember the first full time coding job I had. I was able to work on a great team, on interesting problems. I was able to get into the “flow” that is such a magical state. I was paid well. I had free snacks.
I remember going into my manager’s office and chatting with him. He seemed a bit stressed. He was constantly interrupted. He had lots of meetings. He seemed to want to code, but didn’t have time for it.
Me being the naive young optimist, I asked him once why he wasn’t coding. Why would he leave a really fun job for management?
He looked at me with a knowing smile and said something like “one day, you’ll understand”.
I don’t code for a living now. Oh, sure, I write some code. And it still gets me into flow. And I still enjoy it.
But the honest truth is that when I am coding, I have the leverage of one person. As I grow older, I grow more impatient to effect change in the world. The best way to effect change is to have more leverage. Some options for higher leverage:
leading a team
Most of these involve communicating about coding (or other technical systems), but coding is not the primary work output. Instead, the emphasis is on knowledge or alignment of a team.
Now there are also code specific ways to get more leverage. Two that I can think of.
work on really big systems that have a lot of users (FAANG companies, or something similar).
work on open source libraries or projects that have a lot of users
If either of those floats your boat, then pursue that. I don’t like the first because I don’t really enjoy the bureaucracy and politics of big companies. I am not a fan of the second because I don’t really enjoy working for free.
By the way, no one says you have to have leverage. I’ve just seen that happen again and again across many companies and many individuals. Part of that might be the crowd I run with, but part of it might be that more leverage typically means more pay.
Your career is long. My guess is that one day you won’t want to code for a living. Enjoy it now, but keep your head up and think about what other areas, focusing on communication or team alignment, might eventually be of interest to you. Learn about those areas. Meet people who are currently doing them, and ask questions.
This post from Charity about the choices you face as an engineer, and the challenges of technical management, is wonderful. As a new developer, you’re probably a few years away from thinking about that (but perhaps not. If you join a startup rocketship, it’s possible you’ll be managing people in months). But you have to manage your own career, and moving into management is one of the main career paths for a developer. (I’d say the others include: starting a business, becoming a senior developer, or becoming a consultant.)
Charity talks about how management is an entirely new skillset, and how being a technical leader plus a manager is a great way to get amazing things done. She also covers the negatives of “climbing the ladder” to ever more senior leadership. Charity doesn’t mince words:
Your job [as a newly minted technical manager] is to leverage that technical expertise to grow your engineers into great senior engineers and tech leads themselves. Your job is not to hog the glory and squat on the hard problems yourself, it’s to empower and challenge and guide your team. Don’t suck up all the oxygen: you’ll stunt the growth of your team.
I mean, there’s a reason we don’t lure good people managers away from Starbucks to run engineering teams. It’s the intersection and juxtaposition of skill sets that gives engineering managers such outsize impact.
One warning: Your company may be great, but it doesn’t exist for your benefit. You and only you can decide what your needs are and advocate for them. Remember that next time your boss tries to guilt you into staying on as manager because you’re so badly needed, when you can feel your skills getting rusty and your effectiveness dwindling. You owe it to yourself to figure out what makes you happy and build a portfolio of experiences that liberate you to do what you love. Don’t sacrifice your happiness at the altar of any company. There are always other companies.
I don’t tell you this now, new developer, because I want to scare you away from management. I’m an engineering manager right now and it’s a wonderful place to be. You have autonomy, you can help fix problems you see in your organization, and you get to recruit and help grow people into the best developers that they can be. But just be aware that when you get to a certain level, it’s a one way path away from some of the most fun parts of software development–building things, solving hard technical problems, and being a doer.
Right now, it’s Q1 2019. And there’s a lot of advice you’ll find out here on the internet. Much of it is good, some of it is bad, but the important thing to note is that these are all points of view from people. From that person to be specific. This letter is no different, this is just my view on what matters. Take it or leave it. In fact, that’s the first point I want to make.
2019 tech is full of voices. Social media, popular blogs, and news sites amplify voices and feelings. This is an awesome thing, but remember that loud views aren’t necessarily right.
Find yourself in all these voices. It’s not easy, and it will take time. But work on what you value, and develop your skills to who you want to be. It’s ok if you want to work by yourself on speeding up a search by .01 milliseconds. It’s equally ok if you want to ship a single page app with a brilliant user experience. Listen to the voices when they help, and ignore them when they don’t.
To help find yourself, focus on finding customers that value what you do. Most of the time, these customers are the people in the company you’re working for. But if you want to do algorithms, find people who will value that work. If you want to work on networks, find companies who need that.
It sounds obvious, but it’s an easy thing to miss when you’re looking for a job, and when you’re evaluating comp, culture, benefits, and offices. It’s also really hard to gauge from the outside of a company.
On that note, remember that the 2019 tech industry isn’t how it will always be. Right now, the job market is stellar. I mean really stellar. In most big cities, you can find a job doing just about anything you want, most of the time within a few days.
This won’t always be the case. It wasn’t years ago, and everything comes in cycles. That’s the 2nd point. Be willing to do things you didn’t think you wanted to. I worked on embedded systems when I started my career. I got into web technology not because I cared about it, but because it helped me get a job in a city I wanted to live. Turned out to a prescient choice, and opened up tons of opportunities I wouldn’t have had otherwise.
The tech choices come in cycles, but so does demand. I said before that the job market is stellar. But some of us old timers have been through the downturns. When you’re unemployed for 6 months because literally no one is hiring. When your choice is between a 50% pay cut, or a 100% pay cut. Be wise, be smart. It’s a great time to be in tech, but plan ahead for the times that are tough.
Finally, my last point is to remember that there is a world outside of tech. It’s hard when you’re in it to see that. When tech was smaller, and more insular, it was easier to remember that this is a job.
But now, tech is everywhere. Apps are everywhere. The internet is everywhere. More people are writing code, building companies, and figuring things out. But, tech is not the entirety of life. Get outside of the tech zone, and connect with people who aren’t in it. It will change how you think, and how you develop code. And it provides a much needed break from the echo chamber that is tech.
Good luck, and have fun!
Rishi Malik is the founder of Backstop.it, a company focused on making cybersecurity easy for companies to implement.
This is a guest blog post from Rick Manelius. Enjoy.
Dear new developer,
Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?
Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.
A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials. Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.
I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.
Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.
Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.
To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.
Before I overwhelm you any further…
…there is hope.
You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.
Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.
The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.
Adopt a Hive Mind Approach
We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.
By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.
So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.
Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.
So get out there! And good luck!
Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.
You are probably pretty overwhelmed right now. There is a lot on your plate and you probably are just trying to keep up with the job.
I hate to do this, but I am going to ask you for some extra curricular time.
You need to join a technology meetup. Go to meetup.com and search for one on your area, covering technology that you’d like to understand more about. Sign up and go to the next one. If there’s no meetup in the area, search for a virtual one, and join via video chat or audio chat.
When you are at the meetup, you might have a hard time chatting with people (I do!). I find the best way to do this is to be interested in them. Show up 15 minutes early. Find someone standing alone and walk up to them and introduce yourself. Then ask what brings them to the meetup and what they are working on. This will be awkward at first, but just like coding, gets easier the more you do it. (Not sure how to do this virtually, but try to chat with someone on the webinar.)
Then, sit down and enjoy the presentations. You’ll probably learn something.
Why should you do this?
It will expose you to new ideas that you can bring to your work
It will allow you to have professional conversations where the stakes don’t feel as high (you can admit ignorance to a total stranger more easily than to your boss).
It will allow you to practice networking and talking to strangers, but the topic will be something you know you are interested in.
You can make friends, or at least acquaintances in your industry.
When you are ready to hunt for a new job, you will have a network outside of your colleagues.
You will meet cool people.
You will learn new things.
You may, in time, choose to help organize or speak. These activities are valuable for your work life, but again are easier to practice outside of the work environment. But if all you do is attend a a single meetup regularly, you will still come out ahead.
You have only a finite amount of time, and the world is large.
Technology changes so often and so fast that it can often feel like there is not enough time. Here are two strategies.
The second is to choose whether you want to go deep or go wide. Going deep is focusing on one domain or language and truly achieve mastery. This is a project of years and experience. This path will lead you to interesting jobs and big paychecks, if you pick the right area. If you choose poorly, you might have only a few employers to pick from. Working for a product company is the best way to go deep.
Going wide will mean that you never achieve true mastery. You will however, learn to pick up new skills quickly. You’ll learn to map between two dissimilar situations. You’ll start to see patterns across software development and business. You’ll always be more of a generalist than a specialist, and that will limit some job opportunities. Working for a consulting company is a great way to go wide.
Neither of these is a better path than the other, and you can, especially in your early career, switch between them. Try them both on and choose consciously.