Hi folks, and welcome to the first issue of Code, Content, and Career. My goal for this is to cover each of these areas each issue in some way or another and help you make positive steps in your career in tech. Rather than get into the super technical details, this newsletter will offer my advice and thoughts around what I call “core skills”. It’s my hope you find this useful.
This issue is all about responsibility, from what it looks like to how you hold yourself accountable as you deliver products for people. As you read it, think about how you demonstrate responsibility in the work you do. And at the end, you'll find some thought-provoking questions to ponder.
Active vs. Passive Responsibility
Are you waiting to be told what to do? Or are you doing it before being told?
One of the most impactful things you can do for your career and your relationships with others is to make the shift from passive responsibility to active responsibility.
Passive responsibility is being reactive. Early in your career, you have many people telling you what to do. Someone has decided on a strategy, and it’s your job to implement it.
But the more senior you are, the more you’re expected to be an active participant in the goings-on of an organization. You have to move from being told what to do to being an active participant in figuring out what needs to be done and how to do it.
Active responsibility is proactive. You’re looking around for things that need to be done, and you’re doing them. You’re taking on issues. You’re identifying problems and assembling people to get things done.
Imagine a partnership, like a marriage, or even just with roommates. There are dishes in the sink. Do you see them and do them? Or do you wait and see if someone else will do the dishes? Or do you wait and see if someone asks you (or passive-aggressively tells you) to do them?
You’ll find the same tension on a team where some people demonstrate active responsibility while others demonstrate passive responsibility. Some people will be annoyed that others aren’t picking up the slack, and others will feel the tension and not understand the issue. And some will become resentful that others are pulling ahead. Some wonder why they aren’t getting promoted, even though they’re doing great work.
Well-functioning teams and partnerships are much more likely to have everyone engaging in active responsibility. And folks who take the initiative are the ones who have a much easier time getting raises, bonuses, and promotions.
Take some time today to reflect on the last few months.
Was there an opportunity in a meeting for you to own a project or a task? Did you take it?
Were there things that needed to be done that didn’t have anyone focusing on them? Who did them? Was it you?
Who do you know that models this active responsibility behavior? What do you notice about them?
Now, we’re all busy, and the idea of taking on additional tasks might feel like too much to ask. I’m not saying that you should do more work. But I am suggesting that you think about how you can be a more active participant in the work you’re taking on. You have valuable experience. Don’t let that go to waste!
Make a personal goal to be more actively responsible in the next 30 days. See what happens.
Book Recommendation: Weapons of Math Destruction.
The software we write impacts our society, and as we embrace machine learning and AI, we need to be mindful about how what we create affects those impacted by our code. I learned this lesson firsthand earlier in my career when I worked on an algorithm for an insurance system. We were evaluating biometric data to check for evidence that someone had smoked. We had thresholds we used, and if the data showed that the tests found certain chemicals in the blood above the thresholds, we calculated higher premiums for those folks. It became clear that the code I was writing would impact someone’s ability to afford medical care.
Weapons of Math Destruction takes a hard look at how algorithms impact everything from finances to employment. This book is something I think everyone in our industry spend some time reading and discussing with one another. The more industries software disrupts, the more the code we’ll write will impact society, whether by accident or on purpose.
What will you do when you find yourself in one of those situations?
You used it. You own it.
Developers search for solutions all the time. Google and StackOverflow are your friends if you’re writing code. But whether you’re under the gun to ship a new feature or just eager to get a piece of your project done, don’t forget that you are responsible for every bit of code that ends up in your project, whether you wrote it or not.
There’s no shame in searching the web for solutions to problems, despite what some internet celebrities might lead you to believe. A lot of the work we do as software developers repeats work that other developers did before, and it makes sense to review that prior work before you decide to write your own implementation.
However, the danger you can fall into is substituting someone’s expertise for your own. Searching Google for a solution is only part of the game. The more experience you have, the more you’ll be able to identify which of the five solutions you found is the one that’s the best fit for what you’re doing and which solutions will stand the test of time. And you have a responsibility to apply that knowledge when you decide to use someone else’s solution.
I’ve seen students and professionals unable to explain the code in their section of a codebase, only to discover they found it online and added the code to the project. This is the behavior a lot of the “you can’t just copy and paste code” crowd find irresponsible.
Once you copy that code and put it in your product, you are responsible for it. You have to be able to maintain it. And you have to be able to answer for it when it doesn’t quite work as well as you thought it would. You can’t tell your stakeholders that you found it online. That doesn’t matter. You put it there. You own it.
The same goes for libraries. If you add a UI widget from a library that doesn’t support accessibility, that’s on you. If you brought a library in to handle authentication and there’s a vulnerability, you’re responsible for that. You made the choice. Your peers and those who follow you will assume that you made that choice on purpose.
You cannot write everything yourself, nor should you, so you’ll have to take on some of the risks associated with using libraries or solutions you find online. But you also need to make sure you understand what you’ve added to your codebase, because at the end of the day, you own it, whether you wrote it or not.
Parting Thoughts
That’s all for this first issue. I’ll be back next month with more, but until then, take some time to think about one or more of the following questions:
What opportunities do you have to demonstrate active responsibility in the next 30 days?
What are you working on right now that could positively impact the world around you?
How do you know when to bring a library into your codebase? What do you look for? What obvious signs make you shy away from adding the code?
I’d love to hear your thoughts, and I’d love your feedback on this issue. And if you found this interesting, tell others to subscribe!
-bph
I'd love to talk with you about this newsletter on Mastodon, Twitter, or LinkedIn. Let's connect!
Please support this newsletter and my work by encouraging others to subscribe or by buying a friend a copy of Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.