Lee McKeeman’s Post

Engineer Career Growth, 1st Hire to Independence You learned to code, passed the interview, maybe a successful internship. That’s all over, you made it. Your first job as a software engineer. Whether you’re self-taught or college-educated is irrelevant. You have no idea what you’re doing, nor do you grok half the words people around you are saying. Strap in. How do you progress from newborn fawn to comfort delivering small- to mid-size features independently (often correspond with your first promotion)? Learn. You’re going to learn. You are being paid to learn, soak it in. OK, “learn”, great. How? What? • What is the workflow for what to build, what you need to change, doing that work, and shipping the feature? •What are these “unit tests” people keep talking about. Why am I spending all this time writing them? • Other people look at my code before it ships? I’m supposed to look at theirs? • Someone asked me how long this will take. I said 20 minutes and my lead pulled a bag over my head and dragged me into a closet. What gives? I.e. the arcane art of estimation, and how to convincingly lie about, er “pad”, estimates. • Find bugs in production, especially transient ones, and fix them • Develop requirement sense. What questions to ask when given requirements? • What metrics are, types, why they matter, and how to read them. • Developing a deep love/hate relationship with your IDE and any other tool you use • Calibrating on when to ask for help. Don’t ask every time you get a compiler or runtime error, but don’t wait a week, either • You don’t understand your feature until you can explain it to someone else • What makes for a good design document, and how to respond when in your first review the participants tear it up like the cow lowered into the raptor enclosure • Learn some problems are solved when you’re not working on them, and how to do something else productive when you hit a wall • what to do when you break something really bad, and how to never break it like that again • competently explain how one major subsystem of your product works to a technical peer that has never worked on it • miss a deadline. Understand why. • tell a non-tech stakeholder why something is impossible and have them believe you without your manager or lead helping • Learn that what you built is not sacred. You’ll hate it and rewrite it in a few months, or it will get canceled and never ship • Design a mid-size feature or subsystem yourself, get it reviewed and approved without someone rewriting it, implement it yourself, demo it, ship it, have it work • Find out why that weird thing happened last month via app and data store logs • Come to peace with delivering something imperfect, and know best intentions won’t get it fixed • Have your lead point people in your direction for a subsystem or feature • Document something that people are scared about You’ll get the hang of it. Probably. Good luck, god speed. https://lnkd.in/gvtCUDmG