readme

History

After debating in high school, I entered college as a political science major. I could write (and argue), but I wanted to learn to problem solve and build so I studied economics, data science, and a bit of programming before joining McMaster-Carr as a developer after graduation. During my time at McMaster, I worked on a variety of web, back-end, and infrastructure projects as both a developer and manager. Besides many interpersonal lessons, managing taught me that I wanted my career to have a greater focus on solving engineering problems and so I went back to school for a Masters in Computer Science. My LinkedIn has more details.

More

The transition from a narrative-driven thinker to a systematic one was very difficult for me and I failed at a number of things I tried, including a math minor. Over time I learned the essential skill of all systematic thinking - debugging. Ask me about my other failures and what I learned.

How I strive to work

These practices make my work more productive and enjoyable. It's worth investing in tools and processes that make these practices easier. Think knowledge work tools, not just developer tools.

Practice	Description
See inside	Start with printing: Effective debugging and feature development require understanding a system's internals. Approach problems by building out the functionality to understand a system and changing the system will come easier.
	Visibility is a feature: Instead of each developer adding and removing print statements, create a printing feature. Create a standard vocabulary so that once a developer understands one system they have a short way to go to understand the rest. Consider flags to allow various levels of verbosity and exclude printing from release.5
Document	Why document: When individuals and teams write documentation they scale their impact. More "Written documents are the most scalable way of disseminating information. (Larson quoting Bu 148)" 1 "The best solutions to frequent interruptions I've seen is a culture of documentation, documentation reading, and a documentation search that actually works. (Larson)" 2
	Content over presentation: An organization's expectations and systems should allow writers to focus on content not presentation. In most cases markdown is good enough. More This readme is rendered markdown with a touch of html for the "More" sections like this. I don't love the lines between subsections in this table and could have improved it in html but I reminded myself, "Content over presentation".
	Visible: We wouldn't hide code until its ready for production so why hide documents? Your document pipeline should let stakeholders follow along as documents are developed. Perhaps extend the dev/prod convention to indicate when work is ready for review.
	More: Put conclusions first, make points concisely, and include More sections (embedded footnotes) and references so that the audience can opt into greater depth and reproduce your work or form their own opinions. Documents provide thinking platforms through their collected resources and analysis. The ultimate decision may look nothing like the original recommendation and still the document was a success.
	Gather document data: Documents are products within your organization and you wouldn't be okay with a product that has no measures would you? Gather reactions, comments, questions, and measures of effectiveness. If this is difficult, build tools to facilitate it. More A mini-project on my radar is to demonstrate document data collection by allowing feedback and displaying view data for this readme. Its important to consider the context when determining whether feedback should be public or for the document creators alone. In many cases, like for this personal website, private will be the right call.
Log what and why	Why log: It's important to know what you did and why. In comparison to messages within a channel or emails, logs enforce a formatting convention and searchability that aid discoverability. And like queues in software, logs also create a subscription model that allows interested parties to opt into depth.
	Daily Logs: Sharing a daily accounting of the previous day and intentions for the day ahead help set my direction and let colleagues and managers know when to engage. IC daily logs fit nicely in a team channel. Manager daily logs fit nicely in a leadership channel. Resist the pull to write performative daily logs.
	Decision vs Meeting Logs: Knowledge work produces decisions that grow into code changes and documents. In the past I've logged meetings but wonder if decisions are a more helpful organizational unit.
Learn your context	Learn the mental models that organizational leaders use in order to color in the context in which you work. You'll become a better ally to leadership and gain a deeper understanding of the frictions you face and their possible solutions. More Understand your Team's Productivity - can categorize using Larson's categories - treading water, repaying debt, innovating.2 • How many engineer's are on the team? How many team's on this product? How many teams does your skip-level manage for this product? Have these changed recently? Will they change soon? • What are some examples of features this team has rolled out in the last 6 months? How many of these features were innovation, how many were addressing technical debt? • How gelled is the team? How long has the team existed? How long has the tech-lead been on the team? Longest serving member? Average member? • What are the team's biggest blockers to releasing new features? To answer this, map the development lifecycle using system's thinking.3 What is the team's monthly commitment to on-call work?

How I strive to work with people

The people are the best part of working in tech. They are creative, thoughtful, driven, and self-aware enough to recognize pandering. Even so, we are all human and need reminders. These are mine.

More

These are my reminders and they closely relate to my weaknesses, yours are likely different. Critically important practices that come easy for me aren't mentioned here because I take them for granted. I may add them in the future for completeness.

Practice	Description
Be creative not perfect	Collaboration can turn crazy/stupid/bad ideas into great ideas. Find people who enjoy speculating and sharpening ideas.
Seek perspective and support	Proximity to technical and people problems can skew your understanding. Seek perspective from people outside your team, even your company. They'll see the forest when all you see are trees. They can also help keep you accountable when you need to have uncomfortable but necessary conversations.
It's never too late to build a relationship	Relationships make work more productive and enjoyable and we should invest in them for their own sake. However, even if you find yourself clashing with someone over work it's not too late to build a relationship with them. Their ideas and approach likely have merit even if it differs from your own.
Teach	If you can't put it in your own words, you don't understand it yet. Ask someone to teach you something and explain it back or teach someone new.
Discuss how we work	you.discuss(this, me); For instance, what do you think of this syntax?
Have fun	Professionalism is respecting others and being dependable. If you've got that down there's still plenty of room for fun. We spend too much of our lives working to not enjoy it.

Modes of work that energize me

These are the modes of work that I try to make a significant part of my work week.

Mode	I am energized by
Maker	Focused time to read, write, and problem solve.4
Collaborative	Collaborative time to learn, teach, imagine, and plan. i.e Yes please to a coffee chat but let's walk or stand at a whiteboard.
In person	Serendipitous conversations and personal connection I find when spending time with colleagues in person. This is important enough to me that in a hybrid environment it's worth getting creative with.

Types of work that energize me

This is my ranking of the types of work I find most fun to build and use. I try to work on products with these characteristics. These ranking map closely to the people and ideas that inspire me and are likely the reason why I love to fixate on the human computer relationship.

Type	Description
1. Tools	I strongly believe that our tools shape us. Creating new features, ease, and discoverability for users, builders, and designers gives me lots of joy.
2. Dogfooding	I think that great products come from teams that use their tools. This is important enough that its worth getting creative/having fun with. Empathizing with users is still important because you likely won't represent the diversity of your users but that empathy should follow naturally from your own experience rather than require heroics.
3. Complexity	Complexity creates puzzles and finding simple (even boring) solutions to puzzles is why we engineer. Right?
4. Performance	Performance requires understanding your system's actual not ideal state. This requires investing in tools to measure and understand your system and then creating creative solutions that limit complexity. Performance is fun because its hard.

References