“The Engineer/Manager Pendulum” is a great article about a career shift from engineering to management. Anybody who’s in engineering now and plans or even just wants to become a manager should read this. Anybody responsible for “promoting” engineers to managers must read this too.
1. Becoming a manager is not a promotion – it's a lateral move onto a parallel track. You're back at junior level in many key skills.
Do Not Mix Software Production and Development Methodologies
Use Persistent Storage as an Extension to Human Memory
Stop Wasting Time on Formal Time Estimation
Understand the Cost of Switching Tasks and Juggling Priorities
Use Architecture Reviews as a Way to Improve System Design
Value Team Players
Focus on Teamwork Organization
All of these are good and true, but if I had to pick one, I’d say that rule 4 is my personal favorite. Sometimes I feel like I’ve spent a good quarter of my life in meetings, discussions, and other estimation sessions. And looking back at all of them, I have to honestly say that they all of them were a waste of time. The only useful part of an estimation session is a high-level project plan, but that can be achieved with a project planning session – much narrower goal, much more measurable, and much easier to achieve.
The most valuable advice out of that long article is this one (I’ve heard it before a few times, but it’s worth repeating):
Think about it like sleep. If someone was interrupted every 15 minutes while they were trying to sleep, you wouldn’t think they’d be getting a good night’s sleep. So how can getting interrupted all day long lead to a good day’s work?
Sara Rosso shares some thoughts on what to document and share, after publishing over a 1,000,000 words while working at Automattic. Here’s the gist of it:
If you’re the go-to person for something in your company, consider how much of it is just gatekeeper information you could document properly to help someone else learn/grow from or work on independently.
Separate out processes and historical background from your strategic expertise. Processes and backstory are not really ‘what you know.’ It’s much better to be a person someone asks ‘why’ or ‘when’ to do something vs. the logistics of a ‘how.’ How can and should be documented for others to build off of regardless of your involvement. This should free you up to be more involved in the why, the new, and the next of your work.
If you’re repeating yourself in private chats or (gasp!) email on a specific topic, document it. That’s also what drove me to create this blog – being able to answer someone’s question with an answer you’ve already carefully crafted for someone else is a great feeling (and a great use of your time)!
Will someone want to know why you decided or executed something a specific way later? Share as much background as possible so colleagues are brought up to speed immediately. Share the setup & thought process you went through, where to find more information, and even the facts, ideas, or information you considered but deemed outside of scope for the particular project. My goal is to hopefully never have someone ask “where did this come from?” or “what’s your source?” or “did you consider this?” (when I had) and instead focus on enriching the discussion or challenging my ideas vs. asking me for information I should have provided in the original post.
Gather the best, most complete, or authoritative things you’ve authored and submit them as potential onboarding materials for new team members. Challenge them to ask questions and to find something you need to document.
If important progress is made, be sure to update your documentation, or retire in favor of something newer or more complete. We do this by linking from old posts to new ones, and all it takes is a quick comment and a link on an old post.
Quora thread on “What are some things you wish you knew when you started programming?” is a goldmine of wisdom. Irrelevant of how experienced you – whether you’ve been programming for decades or just thinking about a new career path, which programming languages and technology stacks you use, whether you’ve completed format education or taught yourself everything you know, I’m sure you’ll find valuable lessons and food for thought in there.
David Walsh shares some thoughts on an impostor syndrome. I’m sure anyone in the tech industry can relate. I certainly do.
“Impostor” is a powerful word but that’s how I have felt during all of my career as a professional web developer. I feel like I’ve learned every day of the ride but I feel like I’m way behind. I feel like people see me as something of an expert where I see myself as an accident waiting to happen. I’m a complete impostor. A fraud.
Apart from the honesty of his feelings, I like his ways of snapping out of it. They do work for me too:
Look at your (hopefully decent) employment history and know that, on a basic level, you’re much more wanted than you’re wanted gone
Log onto the IRC channel of a skill you feel comfortable with and answer questions of those asking
Realize that people who consider themselves “experts”, and don’t go through waves of self doubt, are idiots that are so arrogant to not know what they don’t know
Remember the last time a non-developer friend asked you the most basic of computer-related questions
BLOG! The worst thing that can happen is someone corrects you and you learn something out of it
Review your code and find little nits to fix
One other thing that helps me, is this bit by Joe Rogan:
He talks more generically about life, but I think it’s equally applicable to technology knowledge as well.
Amitj Aggarwal, former Staff Engineer at Google (2008-2012), has collected a whole bunch of data in regards to engineers salaries, in USA and worldwide. His points seem to be overly optimistic at times, but I don’t have any links handy to contradict his research.
Here are a few points to get you started:
Zoho, Salesforce pay 40% more than Oracle, Cisco, GE!!!
Top 7% or so engineers at Netflix, Amazon, Google, Facebook are paid more than $1.4M per year. Next 10% make $700K on average.
Facebook has lost relevance to Slack, LinkedIn, Snapchat, Pinterest and Quora. If you are working at Facebook ask for a 50% raise else move to a startup.
Oracle is loosing to cloud startups. If you are working at Oracle ask for a 60% raise else move to a startup.
ENGINEERS DO NOT WASTE MONEY ON AN MBA. You will make 2X more on average as an engineer.
Tableau, Splunk, Slack, Airbnb, Quora, Twitter, Facebook, Google pay more than $320K salary to their top hires. Definitely interview at these fine places. Uber top engineer salaries are $190-340K per year.
Starting salaries for fresh software engineering graduates is now $130K-160K. Ask shamelessly. For the best ones its ~$180K.