I have had the incredible opportunity to work with a wide variety of companies in my career as a software engineer. I’ve worked for a scrappy startup where I was employee number 2 (number 1 started a week or so before me) and was able to make all of the technical decisions for the Android app as well as create the UX. I worked for an agency where I was their main Android person and was able to work on a number of applications and build out an app from scratch for a local startup. I was able to move up fairly quickly at a large corporation where I was the team lead for around seven engineers. I then decided I liked writing code and took a step back to be a senior engineer at an established startup. This is what I have learned.
I Don’t Know That Much
I saw a quote recently from the CEO of Microsoft that went something like this…
Don’t be a know-it-all; be a learn-it-all.
That is an incredibly powerful quote considering it’s just one sentence long. It also explains what every single engineer should live by, no matter what level they are at in their career ladder. I’ll give some examples of how it is setup on my current team.
- I don’t know a lot about animations in Android. I mean sure, I can animation things but I am nowhere close to proficient. One of our junior engineers is, so if I have questions I know who I can learn from.
- When I first started I knew nothing about RxJava. Our intern (now he’s another one of our junior engineers) knew a lot about Rx. So I paired with him and he helped me learn a lot about Rx and I’ve since been able to build off of that.
- My manager can hotfix a problem at 4:30pm on a Friday. I can too, but I probably wouldn’t be leaving at 5:15pm either. So if stuff really hits the fan, I know who I can turn to.
Early on in my career I thought I’d one day be a know-it-all. That’s really not the case though. No one really is, everyone has their weaknesses. My greatest strength has been building out maintainable solutions, when I was leaving my first engineering job another engineer thanked me because the calendar module I was working on was incredibly easy to work with.
Delegate What You Already Know
There was one project where our architecture group wanted us to use Volley to handle networking within Android. I had already written my fair share of AsyncTasks for handling networking and didn’t really have any desire to write another one so I handed it off to another engineer. So why give another person the work when I could already do it without issue?
Have you ever worked with a senior engineer that gave you a project and then proceeded to know the answer to every single problem you ran into? That wasn’t a coincidence, it was by design. You see, I was able to answer their questions very easily and if they had issues with debugging I was right there to pull them off the ledge. I also got to see what Volley looked like through code reviews while the engineer learned all about network requests. It also had the added benefit of making me look like a know-it-all because in that case I was incredibly knowledgeable.
The other upside is you are now letting another person make mistakes and learn something. This engineer was fairly reserved and didn’t have a lot of confidence. I ended up delegating a lot of work to him though because he was incredibly capable, the main problem was he was never really given a chance to succeed on his own. Last I heard he was the team lead on an R&D project.
Actually Listen
I’m still not perfect at this, but the main idea is you have to listen to what others are saying. Sometimes it can be almost like a reflex to hear something you know is a bad idea and start responding, instead stop and listen to them. Don’t make this an exercise of being quiet either, put yourself into the other person’s shoes and try to figure out where they are coming from, especially if you think their idea is definitely wrong (it is usually at least somewhat valid if not 100% correct).
I can’t think of any specific example for this one so you’ll have to trust me. The next time you find yourself starting to answer someone before they have finished their idea, stop thinking, start listening, and try to understand where they are coming from. You’ll be surprised by how different the outcome is.
Let Others Find The Solution
This one goes a bit with the point on delegation. Essentially feel comfortable enough with the task so you can offer advice but remove yourself from the solution. I’ve been surprised how often the solution I had in my head is completely different from the one that another engineer comes up. Most of the time their solution is just as good (heck, sometimes better) than the one I thought of in my head.
The reason to do this is it lets you see how the solution can be solved. So while you already knew how to solve the problem you also have another way for how it can be solved, pretty neat how delegating works can work out.
Fight For The Important Stuff
The last point I want to bring up is to fight for the important stuff. I like to think of the workplace as a currency exchange between individuals where the currency exchanged is good faith. You typically start out with very little workplace currency and so you might do some work that is time consuming in order to build up that currency. Once you have this currency though you should spend it wisely, every time you fight for something you give up a little currency to the person you are fighting with.
So how do you determine if something is worth fighting for? If it’s among other engineers I determine how confident I am in my solution as well as how much I care about the solution. Typically if I’m very confident about the solution and ignoring it will require me to work on a Saturday some weekend in the future I’ll be willing to go to battle for it. If it’s one or the other then I typically mention it but won’t fight about it. If I have no confidence whatsoever then I don’t even bother talking about it.
The other way involves when you are talking with stakeholders or the business. These usually come in the form of bugs or feature requests but I will approach it in a similar way. Essentially I determine if it is possible currently and how much of an impact it will have on our users. If it’s not currently possible and our users likely won’t notice the change then I tend to argue and give up some workplace currency. If it’s currently possible or our user will notice the change then I might talk about the trade-offs but overall don’t put up a fight, and if it’s currently possible and our users will definitely notice it then I don’t bring it up at all.
And that’s all I care to share tonight, about what I’ve learned. There have been many more lessons I’ve learned but I feel like these seem to be the more important ones. The key takeaways are to know what you don’t know, pay attention to others, don’t work on what you already know, and only fight for the stuff that matters.