Tag: Ownership

Raise Your Ebenezer

Raise Your Ebenezer

By | | Comments 0 Comment

Good technologists stress the importance of capturing information in written form. Examples are myriad and diverse: design decisions, code comments, commit messages, operational runbooks, and performance feedback, all of which benefit from being documented for future reference. In this post I want to suggest another data set worth capturing: your work history and professional accomplishments.

Sometimes referred to as a brag document, and much more than just a résumé, a complete log of your work can serve you in several ways. It’s useful to provide to your manager and other leaders during performance reviews season, or to make a case for a promotion. When it comes time to search for a new job, you’ll be prepared to recount your experiences in detail, and provide concrete examples to questions (a post for another day, but good interviewers love specifics). And when you’re discouraged about your future or feel like an imposter in your present, you can review your past successes and remember that you belong.

No amount of detail in your brag document is too much. Start with the what and where, and be specific about your role in the work. Add artifacts wherever possible, such as public links to code, articles, blogs, press releases, or anything else you can think of. Don’t have public artifacts? Make some if your situation allows. I even collect screenshots/photos if they’re not proprietary, or if they help me remember the people that contributed to successes.

Speaking of which, including information on who, when, and why are also critical (and easy to overlook). No one cares about technical minutia if the work didn’t make a difference. Write down the difference you made! Metrics are best (e.g. increased sales, more users, faster response times, people helped), but anecdotes work too. Capturing timeframe is useful to understand context when relating to other work. And documenting who you worked with is useful for multiple reasons: one, it ensures you remember a network of folks who can vouch for your work should you need it. And secondly, it provides context on the level that you were operating at within your organization. This was one of the tricks we Amazon Bar Raisers used to suss out a job seeker’s influence: were they talking regularly with customers and other stakeholders outside their immediate team? How far outside? And were they peers, managers, directors, executives? This context was directly applied to leveling decisions.

Capture your work log in situ. The longer you wait, the less likely you are to remember correctly (“the strongest memory is weaker than the weakest ink” as my childhood pastor used to say). Having a regular cadence can work well. Friday afternoons especially so, as that’s a great time to reflect on your weekly accomplishments.

It’s not just you that’s likely to forget if you wait too long, but so will others who can provide feedback on your work. Few things are more powerful in a brag document than actual quotes from project stakeholders. It can feel awkward to ask, but get over yourself and do it. Ask for both the good and the bad, accept it gratefully, and save it away alongside the rest of the details about a project.

“the strongest memory is weaker than the weakest ink”

If you’re just starting out, don’t overthink the arrangement of info in your brag document. Pick a tool and get started. Especially don’t wait for a manager to do this documentation work for you; career development is your responsibility first, and besides, they probably don’t see nearly as much as you do (doubly true in the age of remote work).

Eventually your document is going to need some organization. The objective is to tell a coherent story that captures the reader’s interest. Chronological order is probably the easiest, and can work if well if you have a mostly linear career progression. Clustering activities by industry or domain packs the most punch if you’re trying to make a case for your expertise in a specific area. Ordering accomplishments by impact, with most impactful first, is a great way to highlight the value you can bring. If you’re building a case for a promotion, you should consider aligning your document to the next-level role guidelines provided by your organization (and if you don’t have such guidelines, ask for demand them).

Finally, I suggest keeping two versions of your work accomplishments. One internal to your current employer that has maximal detail, and one you keep personally, edited down to comply with any non-disclosure or confidentiality requirements you might have. The latter is the perfect source for résumé material when needed.

Happy documenting my friends!

Leave No Trace

Leave No Trace

By | | Comments 0 Comment

Pro Tip: When creating a piece of code or infrastructure that you only need for a short period of time, mark it as temporary, and ideally include a date after which it’s safe to delete. That way in the future, if you forget to delete it yourself, when some person comes across it, they know it can be cleaned up without risk.

This is doubly important if the temporary thing you’ve made opens up a potential attack vector. The canonical example is adding remote IP addresses to a security group, which I had to do just today:

I view the above as a corollary to the Shopping Cart Theory. The world thanks you for your service.

Next To Godliness

Next To Godliness

By | | Comments 0 Comment

For the first five years of my career, I worked for a defense contractor located on-site at an Air Force research facility. My job was to write software, but the lab had quite a bit of hardware as well. Over time, things could get pretty messy as we were regularly reconfiguring the setup, leaving random cables and parts strewn all over the place.

We must not have been unique in this, because about half-way through my tenure there the powers-that-be started a “tidying up” initiative that everyone was required to participate in, up and down the ranks, including uniformed military, civilian, and contractors. Being already something of a neat freak, I bought some split loom tubing (from Parts Express, my absolute favorite source for A/V parts) and used it to bundle all the cords at my desk. Apparently I’d done such a good job that word got around about my setup, and one afternoon the person at the top who’d launched the cleanup initiative stopped by and thanked me for my efforts, and said my desk was the example that others in the building should emulate.

Ever since I learned proper cable coiling technique I’ve enjoyed keeping areas with many of them as neat as possible, ideally with none of them visible. Today I was happy to do so in my wife’s classroom, including installing a light strip since the cubby where her desk lives is in a poorly-lit corner.

I didn’t need much nudging to do this; now the drive to tidy cables is a bit of a compulsion. If I ever see random ones laying about (such as on a conference room table), I’ll coil them out of habit. And if I ever see someone doing it wrong you can be sure I’ll have something to say about it. Yes, there is a right way, and it’s easy to learn with a bit of practice, so no excuses.

Better Together

Better Together

By | | Comments 0 Comment

Today the United States celebrates its independence. Amongst the barbecues and fireworks, it’s worth taking a few minutes to reflect on the significance of this day in history. For me, I’m most thankful for the contributions of this country’s founders to the ideals of good government.

We’ve had no shortage of trouble in living up to those ideals, and I’m convinced that some considerable reforms are still needed given how the nation has evolved (see Breaking the Two-Party Doom Loop for my favorite take on that subject), but on the whole, the system of government we enjoy with its equal representation, checks and balances, and problem solving using negotiation and compromise vs violence, has promoted human flourishing both here and around the world (well, sometimes at least).

It’s been a privilege of mine to work in the public sector for most of my career, and I don’t expect that to change anytime soon, as I’ve doubled-down on situating myself at the intersection of tech and politics. I figure it’s how I can best honor those who got us this far; to continue the quest for developing better governmental systems and policy.

I’m not alone in that effort, as I’ve been able to meet a lot of great people along the way, dedicated public servants who really care about improving lives. Perhaps you too should consider joining our ranks? Governments are positioned to solve numerous problems both big and small, and they need the kind of smart problem-solvers that tech folks typically are. It may not be glamorous, but it’s desperately needed.

For All The World To See

For All The World To See

By | | Comments 0 Comment

Want an amazing example of learning in public, far more comprehensive than anything I’ve described here? Look no further than the blog of Juraj Majerik, where he chronicles in a 34-part series building an Uber clone from the ground up. No detail is spared in his journey, including setting up automated deployments and detailed monitoring dashboards. I’ve never seen a learning project this thoroughly developed or documented. It puts a number of real products I’ve worked on to shame. And his claim of it requiring about 300 hours is impressive as well, I would have guessed higher.

I tip my hat to you, Juraj. May your example inspire many more to embark on such educational adventures.

Slow And Steady

Slow And Steady

By | | Comments 0 Comment

As of today I have a backlog of 49 draft posts going back to 2017. A good chunk of this backlog, especially recently, centers around themes of maintenance, longevity, sustainability, and generally making sure that work outlasts oneself in some form or another. It’s obviously something on my mind.

So when I sit down to write, why do I most often start with something new instead of picking up an old draft? I suspect it has to do with a fresh take being more motivating. For today, that motivation was my completion of the La Jolla Half Marathon. It’s a race I’ve run before, though it’s been six years.

What’s the relevance to the theme that I mentioned earlier? It’s not only that I am still able to run it despite being in my mid-40s, but that I beat my prior time by over 10 minutes (today’s result was 1:56:05). Which means my years of running have created the kind of habits that enable successful long runs with little to no additional preparation (I only signed up for this race three weeks ago, and thus didn’t have much margin to do a ramp-up beyond my normal weekly miles).

Similarly, while I don’t code every single day (nor should I, it’s not the focus of my current role), I aim to do enough programming regularly so that I’m ready to do more if a situation calls for it.

There’s probably also something to learn here about the long-term benefits of keeping systems running that are doing their jobs as designed and continue to provide value, versus continually looking to replatform and rebuild.

In short: maintenance matters.

It’s Never Five Minutes

It’s Never Five Minutes

By | | Comments 0 Comment

There’s no magic method to software estimation that produces perfect results. Nor is it a skill that’s easily taught. For the most part, you just have to start doing it, make a lot of mistakes, and gradually you’ll get better over time.

That being said, here are a couple articles on the topic worth reading:

My own two (or more) cents is that individual task estimates will always have considerable uncertainty, but that can be mitigated by quantity. As long as there’s no systemic bias, the sum of estimates across a set of tasks will become more accurate as the set of tasks itself grows. And any bias that might exist (a tendency to underestimate is most common) can be compensated for by a final multiplicative factor (1.25 is a useful starting point, but can be refined over time).

Further, a diversity of estimates per task also increases accuracy, and directly proportional to the diversity of perspectives brought to it. Have front-end folks contribute to back-end estimates and vice versa; get estimates from both senior and junior level engineers; include people that cut across multiple projects. If nothing else it will promote collaborative conversations.

Here’s a process I use to achieve the above diversifications. It’s most applicable when estimating a project, but could also be used for estimating large features, though it’d be overkill for a single task. It can be done either synchronously or (mostly) asynchronously, and doesn’t take more than a couple hours.

  1. Put together a team of three estimators, ideally with a variety of skills and experience relative to the project being scoped.
  2. Each person reads through whatever project materials have been assembled so far (descriptions of the work, details on the customer and industry, overall objectives, etc).
  3. On their own, each person independently writes down in a few sentences their understanding of the objective of the project. This description should be non-technical and describe business outcomes, not implementation details.
  4. The group comes together and synthesizes their separate descriptions into a unified paragraph they all agree accurately captures the project objectives.
  5. Each person independently puts together a list of tasks to be completed based on that description. These should include everything needed to get to done, including not only implementation but design time, testing, bug fixing, deployments, documentation, and so on.
  6. The group reassembles and synthesizes each list into a unified task list, removing duplicates as needed, and discussing any items that aren’t broadly understood, until everyone feels good that the list is as complete and detailed as possible.
  7. The scopers separate once again, and on their own each person comes up with an estimate for each task on the unified list. Scopers should not get hung up too long on each task; give it a few minutes thought, make a best effort (err on the high side), and capture any assumptions or unknowns.
  8. Once everyone has independently estimated, come together again, and compare estimates task by task (as well as any assumptions anyone captured for that task). If there’s little variance across the estimates on a task, use the average as a final value. If there is disagreement on the estimate, discuss until a common understanding is reached. Reword the task, or split it into multiple tasks if needed, and then estimate those subtasks. If a consensus final estimate cannot be reached after a reasonable amount of time, the largest original estimate for the task should be used.
  9. Sum the final estimates for each task to come up with a total estimate for the project. Each person gets a chance to share their feelings on this total: does it seem right in aggregate compared to the original description of work determined earlier? If so, excellent. If not, re-review the task list and iterate on estimates again, either as a group, or even going back separately.
  10. Collate the list of assumptions and unknowns and discuss. Based on what is identified, decide on a final uncertainty multiplier. As a general guidance, add 10% if the list is short and/or simple, 25% for “standard” assumptions, and up to 50% if there are large unknowns or significant anticipated complexities. There’s no hard rule here; apply professional judgment.
  11. Apply this multiplier to the task estimate sum to get a final estimate for the project. Share it with stakeholders along with the project description and list of assumptions. Be prepared to defend the value, but also be open to questions and challenges.

I haven’t met anyone who truly loves software estimation, but it’s critically important if you want to be successful beyond hobbyist level. Put in the effort as a team and reap the benefits.

Pro-Social Behavior

Pro-Social Behavior

By | | Comments 0 Comment

As someone who tries to maintain a consistent and up-to-date, if atypical, online presence, it’s no small effort to update profiles and such when taking a new job. Here’s the list of the sites I’ve edited recently (documented here as a reference for next time I need to make such changes, if nothing else):

Besides the basic information, over time I’ve crafted a professional profile statement that I use to describe myself. It comes in three flavors depending on length required:

Technologist building systems and organizations that promote human flourishing.

Technologist building both systems and organizations that are secure, scaleable, cost-effective, and most of all, promote human flourishing.

Technologist building both systems and organizations that are secure, scaleable, cost-effective, and most of all, promote human flourishing. Well-versed in programming languages, cloud technologies, and people management. Experienced with the entire engineering lifecycle, from ideation and requirements design to architecture and implementation to sales and support. Also an avid runner, amateur musician, and owner of every iteration of the Raspberry Pi.

When I need a brief personal description, I use this:

husband, father, son, brother, musician, runner, and maker of things

I’ve also used a number of headshots through the years, here’s a couple of my favorites, in reverse chronological order:

  • Headshot by Bethany Zabrosky (2022)
  • 40th birthday (2019)
  • Bass playing photo by Nikki Brill (2017)
  • Headshot by Cindy Kyle (2016)
  • All-time favorite selfie, I look like my grandfather (2014)
Get In The Arena

Get In The Arena

By | | Comments 0 Comment

Several months ago I had a need to cache function results across multiple executions of an API client. A quick web search revealed several solutions, the best fit being cachier. However, it was still missing a few important features I needed, and thinking it was the quickest solution, I wrote up a wrapper to implement these features and published it on PyPI.

One of the features was particularly tricky to get working without modifying cachier itself. Though I did get it working, I regretted not instead simply seeing if I could build my needed capabilities into that library itself and avoiding the wrapper altogether.

Turns out I had some additional free time, and took a crack at an integrated implementation of three key features, and turns out the maintainer of cachier was grateful for the contributions. I was also able to make additional improvements, which benefit all of cachier’s users, not just the one user (i.e. me) of a wrapper which is unlikely to get popular.

This experience was a good reminder that open source software is not built by a mysterious group of “other people” but by ordinary folks who graciously offer their limited time for the public good. Considering how much I’ve benefited from such generosity throughout my career, I’ve been thinking about what responsibility I have to the broader community. I’m not the only one. Do I have a professional obligation, or even a moral one, to contribute? Quite possibly, but either way, it’s something I’m going to do as long as I’m able.

Where My Mouth Is

Where My Mouth Is

By | | Comments 0 Comment

As I get older, the more I’ve reflected on ways I can give back to organizations and communities that have had a big influence in my life. It’s why I contribute to open source projects. It’s why I respond to Stack Overflow posts (or at least try to periodically). And it’s why I give to the Wikimedia Foundation.

Despite it’s quirks and occasional inaccuracies, Wikipedia is a modern miracle of information that has shaped countless lives in inestimable ways. I find their mission statement a beautiful ideal: “a world in which every single human being can freely share in the sum of all knowledge.” Knowledge isn’t everything, but it’s a significant something; a necessary ingredient to human flourishing. And I’m happy to do my part to increase its presence in the world.