Artisanal Concatenations of Sentient Emanations

Numbers are a funny thing, especially when you run out of them. A while ago, I was sitting in a meeting discussing making a series of marketing messages with numerical priorities. I opened my mouth to issue a warning when someone on the team said, “We should assign these messages priority values as multiples of ten for future consideration.” My heart! I blinked back some tears of gratitude, and the meeting continued.

Assigning numbers to things creates some unusual problems. I recall working on a team long ago where we had a series of popups with assigned priorities. The priorities were assigned numbers, with zero being the highest priority. The priorities were also assigned in software by complicated marketing rules, meaning changing these values introduced risk. It should come as no surprise to anyone that, eventually, there was a more important message to send to the user than the one assigned to the highest priority.

The proposed “solution”, which I have seen repeated on more than one occasion, was to create a new class of marketing popups with a higher priority than the existing chain of popups. For fun, let’s call that the super popup.

For a period of time, everything was fine. As with the original popups, a higher-priority popup would eventually be sent to the application’s users. The original popup product manager and the super popup product manager had already moved on to other teams or jobs. The new product manager put together a design for a new system of popups that would be checked before the super popup and the original popup—the hyper popup!

I was in the room when this was announced to the engineering team. You could literally hear souls shattering and sadness exponentially growing throughout the room. One team veteran calmly pointed out that this would be the third time we are building a prioritized popup messaging system and that this one, much like the others, would eventually become obsolete. We would eventually need to display a higher-priority message after popups, super popups, and hyper popups.

There is a lot to unpack here. The first is that decreasing numbers for increasing priorities is a very dangerous pattern. You quickly run out of positive numbers that are less than zero.

The second thing is that while there is something psychologically satisfying about turning increasing priorities into decreasing positive integers, it is upside down and backward. “This is a priority zero!” is a much more satisfying declaration than “This is a priority three hundred and seven!”

In the first paragraph, a wise soul declared that it might be good to future-proof the system by making things multiples of ten. Why stop there? Why not a multiple of one hundred or even one thousand? If you are averse to increasing numbers to represent increasing priorities, you can buy yourself some time by spacing these numbers out into larger values this way.

This is one of those design mistakes that most people learn about by doing once. The first time I had to build a set of prioritized messages, I made this mistake and ran out of numbers smaller than zero. The message numbers were C++-based #define assignments, which meant a quick edit pass fixed the problem. If you are working on a legacy system with multiple client and server codebases outside your control, you would need to do something different here.

That’s it. That is the whole post. This is probably as close to actual coding or architecture advice as I am going to give on my blog. Ideally, you do not have to inherit a problem like this in your career. Also, if you build a set of prioritized items, you pick magic numbers like 1000, 2000, 3000, 4000, 5000 vs 0, 1, 2, 3, 4 for priorities.

The eventual person who has to inherit your feature will thank you for it. See you next week!

To be an effective leader, you need to develop many skills. Communicating is one of the harder leadership skills for software developers to master. One of the reasons I started this blog is to help spread my painfully acquired knowledge about engineering leadership to people… If one person changes their actions as a result of a blog post, then that was a blog post worth writing. Writing this blog is not a community project—I have a great editor and a premium Grammarly subscription. I am grateful beyond words for these two things.

I also write this blog because it helps me be a better communicator. Communication is an important part of leading people, and I have a few more posts about it in the queue.

Today’s post is about editing.

As a leader, you need to apply many filters to your messaging. This gets complicated because you might need to apply these filters in real-time or figure out how to artfully retract or edit a misstep in your messaging. Thankfully, Slack allows you to delete or edit your messages, which is one of the features I appreciate tremendously. You can sneer all you like at me, confessing to posting a message in an incorrect channel or for an incorrect audience. Karma will fax you your comeuppance eventually; it has happened to me and will happen to you.

Here are some filters you may apply when putting your words onto the internet for all eternity.

Does this violate human resources or employer policies?

This is generally an easy one to follow. Most of us have common sense, an understanding of confidentiality agreements, and possibly training about what is and is not acceptable in professional communications.

Am I being unreasonably aggressive to one or more people?

This one is tricky. When you want to give someone really hard feedback, it is important to give it privately. It is also important to couch it professionally. I enjoy the “coaching sandwich” approach to written messages. You start by saying a positive statement, followed by your feedback (generally not positive), and you close with another positive statement.

“Hello, Sam. You just took down production due to an issue in your code. It appears to be a single line change, and do you even test this stuff?” is one way to communicate an issue to a team member.

“Hello, Sam. Thank you for taking point on this week’s release. Production went down for a small window of time due to a small change in the code. In the future, it would be helpful to verify changes, even little ones, to our deployments.” is is a better way to say it.

I do think that there are times to publicly tell your teams that there are issues that need to be addressed. My general approach is to message them privately first. If multiple people are making the same mistake, I might politely message the team publicly once or twice while I figure out what the overall issue is with what I am saying because sometimes the message might not carry the right level of concern or severity. Eventually, I might get to the point where I tag them publicly after I have exhausted all possibility that I am making a mistake in my communications and have given enough hints that I believe the time to wait for habit-changing has passed.

Am I hurting my team’s morale?

This is a tricky one. I have developed a good sense of what doesn’t hurt my team’s morale—by saying enough things that have driven a bus over their morale. Sometimes, I even went so far as to back that bus over the team for good measure, giggling like a madman.

Figuring out the right tone to talk to people on your team takes some time.

“Hello, I need to delegate this task to one of you, my direct reports, so I can do more important things” is one way to communicate that you need something done.

“Hello, I need someone to take on an important team responsibility that presently does not have an owner” is another way that says the same thing.

Here are a few things to note. First, don’t talk about your team as “my team.” Instead, talk about it as “our team” or “us”. I am a big fan of the “we” when talking about work. Second, do not make it sound like the work is beneath you. I will do a shift of QA when it’s needed to get stuff done—I am not proud. Presenting task choices to people as an opportunity to lead and own things is a much better approach than looking for a minion to delegate your work to.

Is this the right time for this message?

There are a few elements to message timing, especially on Friday. Please don’t fuck up somebody’s weekend if you do not have to. If I have bad news for someone, I will do my best to deliver it to them earlier in the week or on the following Monday. I know some bean counters out there will mumble about lost productivity for the dark cloud you just hung over someone’s noggin, but if it is work-related, that should be okay. Don’t send someone home to be all pissy when they take little Timmy to Little League on Saturday morning.

You will also want to avoid Friday if it is an important message. Or, if you have to deliver the message on a Friday, send a reminder to yourself to reiterate the message the following Monday. People will blow up their mental stack of work over the weekend, and if you expect everyone to have full recall and clarity after a Friday announcement, you will be disappointed.

Am I giving enough context for this message?

This merits its own article. Sometimes, people are in the middle of doing something, and when you ask them a question, they have no idea what you are talking about. Not everyone is in your head 100% of the time, and they might not understand what you are asking without a decent explanation. I am working on improving my own context-setting in messages.

Is there anyone I can ask to look at this before I send it?

This last question is the hardest for a new leader to answer. Many assume they must demonstrate that they have A+ Advanced Communication Skills on day one of their job. This is far from true! I will send draft messages to peers, managers, and even select team members who report directly to me to make sure it makes sense. You absolutely are not alone on your road to leadership, and if you have a good relationship with your boss, I 100% recommend that you take advantage of their guidance and advice in communicating with teams.

This brings us to our final two questions.

How do I feel if I pretend to be my audience and read this message?

Being able to read a message as if you are someone else is a hard skill to master. It is also an important skill to attempt. If you cannot successfully imagine how your message reads to other people, your leadership journey will be hard, if not downright impossible.

I feel like I ought to be clapping with each of the last four words above.

If. Not. Downright. Impossible.

I am sorry if I just clobbered you on the chin with a size twelve shoe.

Leadership is hard, and communication is really important. You can have individuals at work with whom you may assume some familiarity and relax one or two of these rules. You will also have times when you will need to go through this list two or three times for a really important message. You should start to develop the habit of reading messages like you are someone else if you want to take your professional growth seriously.

This final question is meant to be thoughtful and to take you away from feeling like I just shoved you down the stairs.

Does this message make sense?

This question makes me want to grab my Slack window and shake it violently. I would love to have some kind of magic voodoo software to parse my Slack messages ultra-fast and better catch goofy typos and incomplete sentences. The red squigglies underneath a mistyped word are insufficient, and I struggle with mid-stream edits when I am urgently capturing or transmitting information. I do not think I am alone in this. I think that we sometimes take it for granted. Some software does better at post-whargarble-entry error correction, and some teams do their own forward error correction correctly enough that it does not matter significantly in some environments. In other environments, you look like a zoomer fr fr, and that might not be a good look.

Thank you for reading along today. I do not have a tantalizing Amazon Affiliate Link for you today. I also don’t have a crappy one.

See you all next week!

I spent some time this weekend assembling an inexpensive pergola that we purchased from Amazon.com. I will not link it here, it is functionally equivalent to a tattoo that says “NO RAGRETS.” As hard as it is to believe, I do not need to steal nickels from Jeff Bezos that badly. I wanted to compare and contrast this with a different purchase I made the week before. I purchased a fancy pillow (and yes, I will steal nickels from the fancy pillow).

The inexpensive pergola aims to provide photon shielding for my children when they enter the backyard. I have purchased enough backyard items to know that everything we leave under the California sun’s withering glare will be swiftly reduced to crumbling rubble. This is even before any planned obsolescence is taken into account. The opportunity cost of buying an expensive backyard item that gets destroyed in equal time is simply too much. You can buy two cheap things and get twice as much utility over time.

On the other hand, I purchased a very high-quality pillow. You will spend hours daily with your face mashed against a pillow. By the same logic, I also want to get high-quality mattresses and high-quality chairs. You will spend lots of time rubbing parts of your body on these items and something-something posture. I would love to take this moment to call out my fancy Secret Lab Co Chair. Unfortunately, none of Jeff Bezos’s nickels get stolen should you buy yourself one of these chairs.

When I said high-quality, you knew that I meant expensive. Some things are worth it at any cost. You cannot really put a price on the quality of your sleep or your posture.

What does this have to do with engineering leadership? Plenty. You will find that there are many things that fall into the same category of Pillows, Beds, and Chairs in the software world. You will spend many dollars on Slack, email, and GitHub licenses. When designing your organization and choosing the products you wish to buy, you must ask yourself, “Am I buying an inexpensive pergola, or am I buying a fancy pillow?”

That’s it. That is the whole post. This is small enough that I could make a TokTok on it and get huge on the socials. Just maybe?

A girl can dream…

See you next week.

I have been coaching and mentoring engineering leaders for at least a decade. There was a recent article in Forbes about formal mentoring, and now that I have mentioned it, I cannot find the specific article. If you feel like using some Google power, there is a whole pile of older ones. I cannot link it because I just hit some monthly five-article limit on Forbes articles. Unrelated to Forbes and its paywall, I learned about some interesting tools and frameworks to apply to mentees as a result of my own transcendental coaching experience.

I recently established a formal coaching relationship for an engineering leader. Finding a good coach is difficult and becomes more difficult because each person responds differently to different coaching techniques.

When I was interviewing one coach, he asked me what specific issue I needed him to help fix. I responded that we do not yet have a particular issue and we just wanted to give a developing leader a coach. The coach was super puzzled by this. He responded, “I usually do not get called in to fix something until after something is broken.”

I had an “aha” moment occur here.

Let’s go back in time for a moment first.

I developed an informal ten-week program for training new managers ten years ago. About five years later, I wrote down all the parts and created a formal boot camp. Everyone involved appreciated the training, and they were surprised how much of it was based on stuff I had to learn the hard way—from the school of hard knocks.

My “aha” moment was that most people generally do not invest in coaching or mentoring their engineering leaders until they find a gap that needs addressing. Rather than ensure they have a strong foundation for leading and managing based on some foresight and preparation, they would rather let people figure out some of the hard stuff and pay for a coach when the gaps are clear.

This strikes me as disturbing.

I respect that bean counters would rather pay for fractional coaching to solve a specific problem. However, I also think that is myopic and dangerous. Suppose your engineers are highly valuable knowledge workers. In that case, you should consider it a wise investment to prepare them to manage said high-value workers to ensure their happiness and productivity at work. Gambling the health and well-being of your engineering team is incredibly risky, and the cost of replacing key staff is significantly higher than the cost of getting coaching for your newly promoted leaders and managers.

One side effect of this is that there are many coaches out there with a toolkit for helping fix specific reactive issues and coaches with a more far-reaching and proactive curriculum of materials.

You can guess which bucket of coaches I have sorted myself into.

• If you are contemplating getting a formal coach, ask them some questions.
• Do you use any formal assessment tools on mentees?
• Do you assign “homework” for items that your mentee needs to work on?
• Do you have a comprehensive list of conversations for every particular mentee?
• How often do you provide report cards or feedback to your mentees?

If your prospective coach struggles with some of these questions or provides evasive answers, they might be a better reactive coach who can help drill down into prospective areas and help a struggling engineering leader with their day-to-day issues.

If they have good answers to these questions, they are more likely to be a good proactive coach.

I do not know if there is any correlation between the two styles. Are people who are good proactive coaches also good reactive coaches? Any answers here would be purely anecdotal.

I do both types. If I have the luxury of time, I like to get started with a proactive set of materials. However, there are times when I am brought in as a reactive coach and have to jump right into firefighting.

My secret hope in writing this is that people will talk more with their existing bosses and leaders about formal coaching. According to Forbes, there are some material benefits to this. I acknowledge that this is a very self-interested statement, and you might argue that this is a sales pitch.

I am not going to disagree.

See you all next week!

I attended an OC CTO Tech Talk this week. The speaker was impressive and told an awesome story about migrating from Redshift to Databricks on AWS. There was a really well-built slide in the middle about the importance of mapping your long-term technical roadmap projects to business objectives and metrics, and this one bullet point stood out to me: “Avoid chasing shiny new tech.” I scanned the audience on this slide and witnessed an ocean of furrowed brows and puzzled expressions. At the end of the talk, there was this hilarious schizophrenic Q&A where about half of the questions came from the audience around shiny new tech and tactical questions, and I had my hand up to ask a series of related questions around soft skills, coaching, and having a mentor.

I talked with the speaker at the end of the event and thanked her for an amazing presentation. We spent a few minutes discussing the challenges of growing people professionally. In particular, we both commented on how there is a decent amount of trauma from previous bosses for most people who join your team at a startup.

Sometimes, managing people feels a little like being a professional psychologist. I first encountered this phenomenon over twenty years ago at Digital Chocolate. I was in my first director-level role and struggled a little with some of the business strategy and product direction. After some of my 1:1 meetings with company leadership, one of my peers, a producer, would ask me how the head shrinking was going. Five years later, I reflected on that comment while managing a team. We hired a new developer, and I spent considerable time unpacking that team member’s issues to help them be more successful.

Let’s fast-forward to today, after many years of high-velocity team building. I have learned that most people’s performance is heavily impacted by their previous managers—sometimes positively and sometimes negatively.

If you have an employee who has had a toxic manager or a manager with a scarce mindset, you will need to spend considerable time helping them work through that trauma to make them successful. I know that my two worst managers have shaped some of my behaviors. Now that I am in a leadership role, I find myself staring in the mirror occasionally to see if I can see them staring back at me. Whatever my faults are as a leader and a manager, there is a subset of behaviors that I self-regulate heavily to make sure that I never manifest them.

I don’t want to make light of people with startup trauma, but making them successful long-term is a lot like rebuilding Humpty Dumpty after his wall incident. It takes a lot of effort to get people into a place where they can deliver great work and feel safe to take important professional risks.

What are some things you should look out for?

The frightened messenger. If people try to hide bad news or get others to deliver it on their behalf, they fear being held accountable for it. If something breaks, it is important to confidently tell leadership there is a problem, especially if it is serious. The sooner, the better.

Swimming in denial. Have you heard someone say, “We will be late on the deliverable, and we will move the deadline by one week” three weeks in a row? Understanding how far something is behind and what needs to be done to deliver something is important. “I need more time!” is not enough. “How much time do you really need?” is needed.

Superman syndrome. Volunteering to step in and stop the bank robbers is also another problem. This is a super serious problem if you save it and still do not manage to move the needle on a struggling project. It is also a problem if you do it too many times because if you are good at doing your team’s work and you do it enough times, they will develop learned helplessness. Sometimes, this is absolutely necessary, but it is less often than most people think.

The hedge-hog. If you think about considering the possibility of contemplating a decision after consulting with stakeholders to align synergies, you might be a hedge-hog. A trivial example of this behavior is asking someone, “What is the ETA for your current task?” They reply, “I am working on it right now!” Sometimes, people do not love committing to dates because they have been punished. It is important to make decisions and commitments.

The hungry hoarder. When I took too much food at the family dinner table, my parents would look at me and ask, “Are your eyes bigger than your stomach?” Taking on too much work and not necessarily reconciling that work against your existing commitments before accepting it suggests that someone may be a people pleaser. If they over-commit and under-deliver, they may have had a toxic manager in the past who rewarded people who would work long hours and try to push through as the hero who saves the day. This is an unhealthy behavior. I recall offering some strategic tasks to a team member as an optional activity. I was interviewing three candidates and suggested they could shadow one or more candidates to see how I do my initial screens. I know they had some tasks that were due soon, and in my mind’s eye, I believed they would decline to do all three if they were worried about missing deadlines. They cheerfully accepted all three optional interview screens, and a week later, they missed delivering on their core work. It was an unfortunate situation.

When I encounter some of these behaviors in team members, I often spend time with them unpacking the source of the behavior. If we can figure out where it started, we can create a plan to fix it.

After giving someone an opportunity to stretch and grow, like the previous hungry hoarder example, you will have a pretty clear “teachable moment” to discuss with your team member what went wrong and help go through the decision-making that led to the unfortunate result.

A previous boss often constructed hard tasks for his direct reports to observe how they got stuff done. He would assign them a challenging project with insufficient information or resources to witness their “default tendencies.” He would do this under a controlled environment to be prepared for their default tendencies when there is an actual work crisis.

It is an effective way to understand what your people are capable of, although it is a bit “old skool” as a way to learn how your team operates.

You cannot learn this early on as a leader or manager. This is one of those things you develop over time through hard practice. You will also develop the skill of fixing team members through breaking deliverables, teams, or entire companies.

Situations like these are why I choose to mentor and coach people. I have had some people who have started a new role, and from the way they describe their new boss, you can tell that there are rocks in the waters ahead. I do feel a certain amount of relief when I can help someone steer through those waters clearly. I also feel empathy during the times when we are not able to clear the rocks together, and the ship gets wrecked. Talking through what went wrong and how to do better next time is a part of professional improvement and personal healing.

I suppose this is where I make the sales pitch. I like to mentor people and help them professionally. Let’s talk if you feel like you have team members in these situations or bosses who exhibit some of these traits and want a partner to give you perspective and help steer you through some of your challenges.

Have an excellent week!

The most challenging UIUX work is in video games. I almost want to stop there and say, “That’s it, that is the whole post.” It is not like I get paid by the word, nor do you click on any of the books or random items I link here with the hope of stealing nickels from the Bezos. Okay, a few of you clicked—enough for me to get paid once in the many years of writing. Thank you for that.

When I was designing my own mobile games, I had a small office located above a Starbucks. I played a game of my own there because a decade or so ago, there was a pretty easy way to get a third of your coffee from Starbucks for free. I remember explaining this to a friend of mine. His wife used to work at Starbucks, and the brand loyalty was so deeply etched into her soul that she got angry at my cheeky stunt and punched me in the arm. If I do not post the sneaky trick everyone in your town is talking about, I fear the internet will punch me.

Enough about Starbucks hacking.

In addition to intermittent free Starbucks coffee, I also went there to test whether my games were good. I would go to the staff or occasional regular that I recognized and thrust a test phone into their hands. “Here is my game!” I would proclaim loudly, “tell me what you think!”

You can guess what happened next: Nothing at all. People would invariably freeze up for two reasons. The first is that they did not know what to do. The second is that they were afraid of doing the wrong thing.

This was my introduction to user testing. I quickly learned I should add animations to my mobile games to help drive decision-making and button pressing. This was the first of many places where I added subtle pieces of animation to help unfreeze people in possession of one of my mobile games. I should have learned this lesson years before while playing Bejeweled. If you stared at their match three board long enough without finding three in a row, it would give you a subtle hint that there was a possible match. I confess to being so focused on getting that dopamine fix from counting to three that I may have missed the learning moment.

This is an essential thing for game developers to learn. Okay, there two things game developers should learn. First, you should always try to put your game into “n00b” players’ hands to see whether your game explains itself without you, the developer, talking. Your players might not survive by their wits alone. Second, player testing is incredibly valuable. The more people who play your game who satisfy the requirement of being “not you,” the better off your final product will be.

That’s it. That is the whole post.

See you all soon!

I have often said, “Good teams build products. Great teams build tools.” This has become a part of me over decades of shipping software, both good and bad. The best software I have ever shipped has included many tools for operators and intermediate users.

Over those two decades, I have also encountered a few moments of regret. One of the most frequent regrets occurred when I wished I had access to libraries and tools I had developed elsewhere. If I built a nice kernel-level memory management library in C, why shouldn’t I be able to use that elsewhere if the two companies are not competitors?

I had to throw in that last question because I am sure every armchair software developer was halfway out of their chair to demand “whaddabout competitor?!” Checkmate, dear reader. I am way ahead of you.

Setting aside the competitor issue for the moment, I just imagine needing to call a plumber or an interior decorator, and while I require their specialized knowledge and services, I do not run out and buy them an entirely new set of tools to do my job.

I am reducing this absurdity on purpose. I have not felt this particular type of regret in a while because part of what I have done over the past several years is build some software as a consultant, where I changed the underlying assumption about what I have built from a work-for-hire basis to that of a licensing model.

Part of the reason I did this was to give a steep discount to some customers who were not well-financed. Finding cheap product market fit is attractive, and I priced these projects accordingly. The result was that I built a gigantic pile of libraries for several companies, which I now own.

I have gone through these repositories a few times over the years. Some of the time I cackle and imagine I have a gigantic trove of riches. We all know this is fiction. My dragon hoard of software is not a pile of golden coins and gemstones. It is essentially a collection of half-eaten sandwiches and discarded pieces of lumber.

However, I intermittently have a library for timestamp management, database access, authentication, or similar core technology that enables me to build something swiftly.

I think there is a case to be made for software developers to build and maintain their own tools over the years. I can appreciate the IT department manager developing sweats and anxiety at an army of developers showing up with their personal laptops, fully configured to work, with access to their own code libraries. After all, a good chunk of software projects these days start with a pile of npm install instructions or similar that fetches open-source libraries from a billion places.

I exaggerate slightly and with good reason. In the era of the LLM, I can envision developers who have trained up their own AI to solve specialized problems for them. Does this not enable them to do their jobs more effectively?

I feel like I have to stop here. The world is not ready for this flavor of crazy. The IT department of Giant Mega Software Concern can stand down and move the minute hand of their doomsday clock back from midnight.

I wanted to make sure this was written down somewhere, so when this becomes normal in five, six, or even ten years, I can send links to the young peoples and leap up from my chair, pointing and screaming furiously, “See? SEE?”

I do believe a day will come when it will be normal for people to BYOT (Bring Your Own Tools) to work.

See you all next week!

Hello, everyone. I am glad to say that the majority of my move is behind, as we are down to a single-digit number of boxes left to unpack. There might be a future blog post about John’s unhealthy fixation with cardboard boxes or the wonderful feeling of removing a good percentage of your household items through yard sales, donations, and dump runs. As a matter of principle, I may want to do this every five to ten years. 

Many people ask me what I think about AI, and more specifically, AGI (Artificial General Intelligence). I have two replies. The first is that I wrote a story about how that will end. You can read it on this very blog. The second thing is that I do not think LLMs will get us there.

I think a second generation (Third generation? Fourth generation?) of AI systems will soon be coming and will have a better symbolic understanding of the data. The investment frenzy for those systems and the startup companies that create them has not yet begun.

The symbolic understanding of the data is important. The only reason current LLM systems can answer the question, “What do a fire engine and a book have in common?” is because someone typed it into the internet already. We need an AI system that spontaneously, without prompting, creates jokes with that level of cleverness. The spontaneous creation of new ideas, and eventually new science and mathematics, is the part that will tip it over into AGI territory.

Until then, everything we read from current AI systems is just a highly plausible set of words calculated from a subset of gobbledygook that humans have saved onto the Internet. Paragraphs of text read like they were written in a hurry by a tenth grader who has an essay due in nine hours, not even considering the high level of hallucinations that sometimes find their way into the output.

The AGI system that will eventually exist will combine multiple generations of AI systems and add a top-level layer of autonomy, asking, “Is this what I really think, or at least, what I really want to say?”

When two different instances of the AGI software answer Spock’s Mom’s question (go ahead and Google it if you are an unlearned heathen) in a way that makes justice systems of the world contemplate making it illegal to hit the off switch, AGI will have arrived.

See you next week.

Last week, I did not have my machine assembled, and now that it is physically set up, this week, I am not mentally set up due to all of the box ferrying: up the stairs, down the stairs, open the box, empty the box, repeat.

I promise I will resume sending you all Amazon links and industry rants next week.

I have talked to aspiring engineers about professional skills they will need that not taught in school. Some of them are technically taught in school, although they are taught poorly. Version control systems are a great example of this.

While getting the basics for fetching code, creating branches, and committing code is nice, that is not the education you need with version control software. I will use Git for our example today, although it could just as easily have been one of many different flavors of version control. Perforce comes to mind as a version control system that video game developers use because it manages large repos of game assets nicely.

The things you need to learn about version control are more related to merging code and how to deal with a repo that four or more people are actively working on, sometimes even editing the same file. This is not what you get to do in school unless you are working on some kind of capstone project. A week-long project with two or three developers does not get to the level of excruciating pain and suffering that results from four or more people actively working in tandem on a codebase. You seldom get projects with enough people, and you are not working on a project for long enough for the pain to really be felt.

It raises the question: “What is the reasonable expectation for source control proficiency for a new employee without any experience?”

The answer is: “Git proficiency is not a reasonable expectation.”

There is a moment of cognitive dissonance when a new employee asks for help with a git merge. “Hey,” You might be tempted to say, “Didn’t you submit your code sample from a git repo?” While that is a perfectly reasonable knee-jerk reaction, it is not really a good one. Merging code into a large project on a team is not the same as “one person writes a small piece of code and uploads it in a controlled environment with no one else touching it.” It is not in the same ballpark and probably not even in the same league.

You are left with two options.

The first is to buy one of them there goofy mugs with all of the Git commands written on it and to have them hunker down and “git gud.” Maybe this works here and there. I do not know if it scales well. If you want to try that, you have the Amazon Affiliate Link to buy it. I will thank you for them tasty Bezos nickels if you buy one.

The second option is to have them look at using nicely written GUI tools to do their Git management.

I am a fan of the second option. I have used Sourcetree to great effect with new engineers, technical artists, and other team members to solve Git issues. Sourcetree is reasonably good and it is free. It is also a Gateway product to Bitbucket and Atlassian products. Consider yourself warned.

Other people use Smartgit, a fine alternative. It just costs the monies.

Visual tools like this are a reasonably good and fast way to teach new hires to triage repo issues effectively.

In the long term, is this a skill you will need to be a successful senior software engineer or architect? Possibly. Some people get quite good at using visual tools to manage the repos for their whole organization. Some people need to go to the command line, possibly out of personal choice.

The point I want to make is that this is not an urgent skill to learn right out of the gate. If you do need it, maybe, in several years, you will have time to learn it. There are enough important things to learn as a freshly employed software engineer that this one is worth punting down the field a little.

Thank you for coming to my TED talk!