Do you wish you could force people on your team to tie a commit message to a particular work item? Would you like there to be specific text in a commit message to help you tie it to an area of your application?
For some of you this may seem weird — it’s just code, after all. But in some industries and in some work cultures, being able to tell what you affected with each commit is important. It’s for you that the git pre-receive hook provides a solution.
I built this pre-receive hook in 2016, when I worked at a company that had a requirement that commits be tied to work items for “traceability” purposes. It seemed weird to me at the time, but since then I see its value. Developers work at the level of the code and of the commits, and seeing what work items (or “tickets”) a particular commit is tied to gives us a placeholder for that ‘why’ was this done.
Here is a link to that gist I created. In the future I’ll go into what git hooks are, and how you can create your own git hooks, for now, enjoy my rather terrible Python and this rather useful git hook.
Why do we watch all of the Marvel movies, and why do we ignore the DCEU movies? Why do we get so angry at the outcome from Star Wars: The Last Jedi, but not at our own politicians? Why do some software companies evoke a strong reaction (positive or negative) while others we are “meh” about?
We love the Marvel movies because they have good characters and actors — sure. We love them because the movies are compelling, I’ll grant that. But why are they compelling? What did the MCU do differently? Remember these were terrible movies in the 70s, and the characters were far less compelling than Batman and Superman. From the very first MCU movie, they showed us something the DCEU hasn’t:
(obvious pun aside), The vision to say, We are building something you haven’t seen before, and you may not know what form it will take yet, but you know it’s going to be big, and you know — in a way that’s impossible to reason about — that you want to be a part of that.
Do you feel that in your day-to-day work? Do you feel as if your software leaders (or you, if you are a leader) have a vision for the software you’re building? A highlevel of the what and why you exist? Why you build this software together?
If you do, you may need to repeat it often to yourself and others. Paste it somewhere everyone can see it. Make it your Slack opening message or your Jira Welcome screen. Vision is one of those intangible requirements for good software, and it must be constantly communicated to be heard and understood. If you’re a junior developer or not yet in a leadership role, it’s also your responsibility to figure out what the vision is for the software you’re tasked to build. Not its outcome, but the glue that makes all of this matter. The outcome is usually “happier X” But that’s not a vision. Ask your leaders what their vision is. Repeat it back to them. Refer to it every time you’re asked to do something.
Marvel’s original pitch for the MCU was to reshape the storytelling we do in movies by creating a shared universe that transcended characters. They pitched the Avengers before they knew whether or not Iron Man was going to succeed at the box office.
Can you imagine that? Saying to your bosses: Give me hundreds of millions of dollars to roll out these movies, to do something that has never been attempted before in Hollywood, and guess what: There’s a good chance it’ll fail.
The wonderful thing about having a vision for your software is that all those bike-shed-y decisions that feel impossible to get through become easier to figure out. Does this feature align with the vision? If yes, keep it. If no, defer or delete it.
I grew up being reminded of the importance of keeping and taking notes. I still remember fifth grade where our teacher reminded us daily of the importance of taking notes. Her curriculum was built around reading the book and taking notes from the lectures. At the time, it was an alien concept to me. I had a good memory (or so I thought) and it didn’t make sense to take what someone said and to write it down. And so I half heartedly did so, It really wasn’t until college (!) that I really learned the value of taking notes. It was macro-economics, and our professor was a Keynesian so there were lots of charts and graphs. I dutifully copied those charts and graphs and took notes. Since I wasn’t a Keynesian it took me a while to pass that class (2.5 tries), but when I did I received a B+ (I’m still a bit irritated I didn’t get an “A”, but as I said, I’m not a Keynesian).
What happened to you yesterday? As you read this, recall the work you did, and recall what happened. If you encountered a bug, what were the particulars of that bug? What behaviors did you see? What systems did it affect? How did it affect them? Did you solve it? What was the resolution? What was the error message you got?
If you’ve got a really good memory, you probably remember all those little details. If you’re like me, you probably don’t. Most of the details, sure, but there’s an essence that’s missing. You can’t really put your finger on it except to say there’s a piece you’re missing and you don’t know what it is.
Now think back to two weeks ago, or a month ago. What happened with a bug you were working on then? How about a team meeting? How about a 1:1 you had with your manager? What was discussed? What did you agree to?
That’s probably a bit fuzzier.
We live in a world where we are bombarded with information every minute. We filter it out mentally, and remember clearest the bits that have a strong emotion tied to them. And that’s normal. Without that we would be cursed with remembering everything, and our minds know that’s probably overkill.
But, there are important pieces of information hidden in the parts we’ve forgotten. Bugs especially have a nasty habit of being very particular about how they occur and under what conditions and how they get resolved, and you never really know if you’re going to see the same bug again. They are, by definition, unpredictable.
For me, I handle this through an admittedly old-school method. I carry around a composition book — just like the ones we had in gradeschool. I use it to take notes on everything that transpires in my day: bugs I’ve found and how I fixed them, processes, designs for new features, writing ideas, turns of phrases people use repeatedly — anything that gets said where it sounds like the sender feels the information is important. I keep them, and I fill them up chronologically. So that 6 months from now I know what I did today; and I know how it went. It’s not as cool as the video logs from Star Trek, but it gets the job done. I’m able to know with confidence that I’ll be able to find something important 6 months down the road, no matter where I’m at or whether I have my laptop with me. Unlike laptops in meetings, taking notes has a certain social cachet, and no one ever implores people to take less notes.
Give it a try. Buy a composition book (it holds together well, and the pieces don’t tear out), and take notes on your day. If you’re a programmer, record the items you work on, and what you did with them that day. Record bugs you encounter and their behaviors and resolutions. Record the steps you took that didn’t work. Use it to doodle designs for things you’re working on, and use it as a record of your professional day — for tech and non-tech issues alike. After you’ve been doing it for 30 days, look back on day 1.
Soon after starting my email newsletter, I started working at a ‘whale’ client and my spouse started her final year of grad school. I let this blog (and that email newsletter) go because I didn’t want to write about random things — I wanted the content to be focused on something that could provide measurable benefit to others and give people a reason to subscribe. I also started the email list because “that’s what you’re supposed to do”, and so I did it. Aimlessly, of course.
Since that time I’ve been digging around and wondering how to turn what I’m interested in into something that’s useful for others.
For my entire career I’ve been extremely interested in and incensed at the state of software project tooling. I believe we live in the dark ages of developer productivity, and I believe we can do better.
Our software ALM (Application Lifecycle Management) tools aren’t designed to produce software in an efficient fashion. They’re not optimized for software teams, and they don’t work the way that you and I work. They prioritize work as a discrete thing that is identified by a number, instead of the outcome we hope to achieve. We’ve grown to believe that passing that number around from various people will result in the best way to build software. They provide a one-sized fits all view of the universe, whether you’re a project manager, scrum master, QA, software developer, designer, business analyst, or Pointy-haired boss. They’re not even optimized for software developers — the same people that built the software.
Along the way, we’ve been somehow conditioned to believe that JIRA and TFS are “good enough”. That somehow, the mediocre results we get from using them are to be expected, and we can’t do better. For all of the tools we use to develop software, from Git, to Slack, to Google Docs, to our calendar systems to Jira and TFS, we’re somehow stuck in a joyless existence because our tools are the way they are and we can’t improve them to fit our workflows or to make our lives easier. It’s all piecemeal, it doesn’t work together, and the friction hurts team productivity.
I believe we can do better, and I believe we can have software that’s truly optimized for helping you achieve your best results, every day.
To get there, I’m taking this formerly aimless blog and email newsletter and doing two things:
1. I’m focusing on software productivity. If you’re involved in building and shipping software, I’ll be talking about the tips and tricks to help increase your productivity. I’ll go into the tools we use and how to make those better, I’ll talk project management-y stuff, and I’ll be diving increasingly deeper into it, with you joining me on the journey. The content will range from mental mindset to technical topics and everything in between. We’ll talk about the squishy and the bits and bytes, sometimes in the same post.
2. I’m changing the frequency of emails from weekly to daily. This itself may seem weird — George couldn’t ship weekly — what makes us think he’s going to ship daily? Habits are hard to form, and infrequent habits are the hardest to keep. The goal is by instilling a daily habit it becomes easier to keep.
So what does this mean for you? If informative (and hopefully interesting) content on developer productivity is your jam, then you’re in the right place. If you build teams and build software, and you’re interested in spending less time spinning your wheels, you’re in the right place. If this isn’t your cup of tea, no worries, I get it.
I’d love to hear from you. What tools do you use to build software? What do you use to track work? What do you use to collaborate?
Life is overwhelming at times. For instance, my entire week I’ve been mentally preparing for a rehearsal dinner on Friday and a wedding out of town on Saturday, and how to juggle that with three kids, and the inevitable complications that arise when you ask children to sleep in unfamiliar spaces. It has… shall we say, consumed my thoughts. If you combine that with the current goings-on at Stack Overflow, it’s easy to get caught up and not get any work done. If I’m being honest, my mind is also awash with the fact that the Nationals won NLDS game 5 last night in the 10th inning with a grand-slam from Howie Kendrick to make it 7-3, after being down 3-0 when I went to bed in the 4th inning.
But what about today?
Today, I dive into Entity Framework in a hybrid code-first / locked-down change management scenario and build new functionality around email sending. I’ve scoped the problem down to something I can get done today.
It’s freeing in a way. I know that for the next several hours, the only thing I need to think about is that task before me. By the end of today, it will be done. Everything else, as they say, will keep.
TFS and JIRA don’t help in this regard. If you look at the ‘board’ (if you’re doing Scrum or Kanban), you see what’s in the sprint backlog. You see what’s coming up, and you know that no matter what you get done today, there’s more after it. You can see it. It’s ever-present. It doesn’t allow you to focus on what’s important — the right now. It is always in “sprint” view, showing you your work in relation to everything else the team needs to get done this sprint.
If you’re at work, you’re probably thinking about that right now — why am I reading this blog post when I have this story to finish?
While our tools have failed us, there’s something we can do to combat it. This has helped me when I’ve made a conscious effort to allow it to.
I make a deal with myself.
Forget about what you didn’t do yesterday. Forget about what you need to do tomorrow. And for just a few hours, forget about your todo list outside of the work. For the next few hours, you have one thing to do. That next thing. Whatever it is. Focus on that, and shut the rest of it out of your mind. Just for a few hours. It’s the only thing that matters — for the moment. The rest of it will keep.