Be Your Own Boss
No, this isn’t about working a four-hour week, or starting your own company, which are fine topics for another day. Being your “own boss” is about having the honesty, technical expertise, and sound judgement to govern yourself, even though on paper you might report to another person.
If you’re not your own boss, you’ve become passive in the direction and velocity of your career growth, dependent on others for shaping your career instead of owning it yourself. Here are a few key facets of self-management that can help you guide toward being an independent professional developer:
Honesty
You have to be honest with yourself, and with others. Almost everyone makes mistakes from time to time. When you don’t do a great job on a task, allow a moment for an internal postmortem and let yourself say, “Darn. That really wasn’t great. I missed something, it’s my fault, and I can do better next time.”, and be prepared to say this to your colleagues and superiors. Nothing erodes trust quicker than someone denying responsibility, trying to direct blame onto others, or recharacterizing a mistake as bad luck or a “crazy coincidence”. You won’t necessarily lose your job over these things, but lack of trust will leave you relegated to smaller assignments, fewer promotions, and less opportunity to showcase your abilities.
On the flip side, learning how to stand your ground and argue calmly from a position of strength is important too. As you move up the responsibility “pyramid”, you may have ideas that will challenge the status quo. If it’s clear that what you’re proposing is in the best interest of the company, that you understand the counter-arguments and are not acting simply to increase your budget, staff count, and so on, you’ll find more traction for your ideas (because they’ll be both more grounded, and you’ll be more dependable source of advice).
Expertise
Software is a technical field, after all. You have to actually know things. If you have to lookup everything1, that’s not a good sign. If you find yourself receiving criticism for immature code, lack of tests, not having builds automated and so on, you need to sharpen your chops. You can’t play pro golf unless you can routinely break 70, and although it’s harder to measure and not as competitive, working in a technical field requires competency all the same.
At its essence software developer is really about being right a lot of the time. The more you already know from past experience, studying or side projects, the more success you’ll have. It’s pretty simple.
Some other aspects of technical mastery:
- Are you producing high quality code and tests? (Or presentations, sales pitches, whatever your particular role calls for.)
- Are you doing enough work? You should have a sense of whether or not you’re finishing tasks on time (and to true completion), so that you can move on to the next thing.
- Are you doing too much work? You should be aware of over-committing, especially if that leads to under-delivering. There’s lots of reasons why we agree to do things, but in any case, you must have a sense of how much work you can truly handle, and be able to say “no” when appropriate.
- Are you good at reading code? This is critical. Lots of developers can write stuff from scratch, but it takes patience, experience and a decently large mental buffer to comprehend an existing system. Being able to effectively read and debug code will allow you to make efficient bug fixes and minor improvements, without needing to start over just so you can understand it all.
Sound Judgement
My favorite shortcut to clarity when I’m not sure how to proceed with a tricky task is to think and act as if I’m the owner. What would I do if I had to pay the bills, answer calls from annoyed customers, deal with bad reviews, worry about hiring competent people, and so on. There’s tremendous pressure on ownership (or executive management, once things are big enough) to balance all these factors. Committing tons of time to rewrite that old PHP code may seem like a reasonable choice at “ground level”, but it may not be that important to the company. Try to lift your head above the clouds from time to time and get a sense of what’s going on across the business. This will broaden your perspective, and ultimately let you work smarter, not harder (rewrites are tough, after all).
Also, ask questions! In most cases, software development is done best through small increments with rapid feedback2. Don’t be afraid to ask questions like: - What are we actually trying to achieve with this? Why? - What’s the minimum piece of this that I can deliver so we don’t “boil the ocean”? - Has anyone done this already?
These types of questions, asked during sprint planning or when items are added to the backlog can save a whole lot of “tail-chasing” doing work that is simply not needed.
However, know when to stop asking questions (this is part of having good judgement). Although software companies are filled with bright, motivated and capable people, sometimes the work just has to get done. Anyone can have a good idea, but the ship can really only go in one direction - someone’s idea is going to carry the day, at least for a while. Make sure questions don’t turn into stonewalling or unresolvable arguments, and don’t be afraid to step away from a contentious issue. If you’re not ultimately in charge of a particular decision (most of us aren’t), remember that Escalation is not Taboo3, and let whomever is responsible for both sides of the issue make the final call.
Counterpoint
Please note that being your own best critic does not mean aiming for perfection in everything you do - that’s a whole other can of worms that maybe we’ll discuss in a future post. Just be honest with yourself, allow yourself to fail, admit when it happens, and do better next time! Perfectionism, on the other hand, leads down a road of paralysis (never releasing code because it never can be perfect), and even self-hatred if it means you won’t let yourself have any success.
Take Action
A good manager will observe all these qualities in your work, and help you down the road toward being your best, but the world is an imperfect place. You’re likely one of many direct reports to a manager who has loads of other stress factors in their day, so while their feedback is valuable, at some point you need your own internal system in order to make consistent progress toward your career goals.
-
This is perhaps the most common thing I hear when interviewing candidates. “No, I haven’t worked with xyz, but I’m actually really good at researching new things.” That’s fine, but only up to a point. Depending on your seniority level, having proven experience in a particular area is what you’re getting paid for. ↩︎
-
Yes, Agile. Not necessarily Scrum though. ↩︎
-
“Escalation is not Taboo” was discussed at a fantastic presentation on development culture at AWS re:Invent 2019. Although the slides and video don’t seem to be available, the key takeaway is that there should be no stigma in kicking up a disagreement to the next highest level of management/oversight. ↩︎