Advice I Wish I Had at the Start of My Career
28 Jun 2020Advice I Wish I Had at the Start of My Career
While thinking through my career, I thought about the answer to the question of, “What is some advice I wish I had at the start?”
I’ve been writing code for a long time and have had many jobs - I want to share the things I wish I knew way back then.
“Focus young, Thompson - Focus”
At the start of my programming career, I wasn’t focused enough. I was just hanging out in some ways because I was sure that my charm would get me to the next level. That was foolish. I should have set my intentions to be productive and taken breaks when I needed them. By set my intentions to be productive. I’m really talking about going into work knowing that today I will be productive and get my tasks done. I know this may sound like basic advice but if you pay attention to your habits you might find that you are wasting time.
Now, I use a tomato-timer to regulate my work (tomato-timer.com). It helps me to know when to take a break and when to dig in.
“Always be productive”
I got this advice from my mentor, but I didn’t really understand it back then. He suggested that instead of reading random websites, I should have just gotten up from my desk and took a walk or read about some technology that could help learn. You’ll hear me mention breaks a lot in this post and that’s because I’m a big believer in breaking up your day to keep your productivity levels high. Reddit might be really intriguing or you might want to get into an argument on hackernews BUT it might serve you better to read about new features of your language that you work in. Plus, when your boss walks by this will look great. If you are exhausted - take a break, stretch and come back refreshed.
“Pay attention to the trends”
The industry changes a lot and something helpful is to know where the industry is going. I don’t mean necessarily should you learn Vue or Svelte, but instead, perhaps you should learn more about how front end development is changing. Even better, read a technology trends website like RedMonk’s language ranking. See what’s happening around you so you can better prepare. Back in 2011, I predicted our current shift to the front end. I jumped in on Angular and JavaScript, but I didn’t see the trends changing for back end development in 2006 so I initially missed the rise of Spring and the MVC pattern as we know it today. I ended up playing catch-up here.
“Learn about something different than you know”
If you are a Front End developer, check out some Back End developer stuff. If you use JS, learn a little about Java or Rust. The value you’ll get is having exposure to different programming patterns and how that can help you in broadening your thinking and deepening your learning. There’s a great book series called 7 Languages in 7 Weeks that goes deeper into why this is valuable, too!
“You don’t know what you don’t know”
This was a BIG ONE for me. Not being aware that I didn’t know what I was missing held me back for a few years in my career. It’s really hard to see yourself the way others see you. Getting a mentor helped me to see the blindspots & helped me to come up with a plan to fix them. But you also have to be open to the feedback instead of just shrugging it off. When I get tough feedback that I may or may not agree with, I like to ask myself “Is there a grain of truth here?”
The answer is usually yes.
“Don’t be afraid when you code”
Have you ever sat there looking at a screen (blank or other) just paralyzed? Afraid to make a change because you don’t want to break things even more? Well - me too! But remember, it’s already broken so just make a change and revert if you have to! This is why we have git and other version control tools. You can make a checkpoint in the code (commit) that we can use as a jumping-off point! Now hack away! You can’t break it any worse. Rollback to that commit if things get too dodgy!
“Learn how to estimate!”
Remember that timer I mentioned before? Well, it can help you find out how long it takes you to do tasks! This way when your PM asks how long for this task, your heart can say 15 minutes but your brain will say, “5 hours”. Your brain is right.
I’m notoriously horrible at estimation because I always want to get things done in the most optimistic case when it should be more towards the unexpected path and the costs that come with it. Think of it like this - if you are over by 10 hours the problem isn’t that it took you 10 hours, it’s that we planned for it to take 2. There’s a big gap in the estimation vs the actual. You are NOT happy when a mechanic says $200 for the estimate and it’s actually $1000. You’d ask what in the heck went wrong.
“Stand up for yourself”
We’ve all worked with the brilliant jerk. I regret not just coming out and saying, “Your behavior is unacceptable. If you wish to talk to me, then you’ll need an appropriate tone. Or else, we’re going to have to escalate.”
I know it takes a lot of bravery to say it, but I wish I had. There are so many times I’ve had to approach this type of dev, with hat in hand, just trying to get help. This should not be the story. Managers should not cultivate a team that operates like this.
Here’s a thought (me speaking as a manager): “Yes you are talented, but there’s someone else out there just as talented with a better attitude.”
“Always Negotiate”
I don’t even give a number until I’ve learned whether or not I want to work in a place. I know it’s not always easy to hold your ground on this one. But companies know if they can afford you when they start the convo. If they insist on you giving a number, I’d reply with something like, “Sure thing - what’s the salary range for this role?”
Ask for what you want - don’t be scared.
If you like content like this and want to get more of it, won’t you consider signing up for the email list where you’ll get the best, freshest content first. Sign up right here!