Author: jszeder

People often wonder why software developers make the big bucks. We sit in comfortable chairs tapping clicky keys all day and enjoying a multitude of sparkling water flavors wherever we go. There is often a lot of watching of cat videos, and sometimes, there is the playing with the nerf guns. All in all it seems like an idyllic life.

That is during “The Good Times”. When people are attending The Status Meetings, and The Product is following The Schedule. I have sat in these meetings; where people with fantastic job titles throw around these words like they are religious incantations; capitalized and nearly without meaning. “How will this Change Request affect Quarterly Revenue” a high priest of product management may intone, not actually caring about the actual content of the change request. There is no greater incitement to violence in the soul of a knowledge worker than the presence of such monsters. If you have ever sat with me in a meeting and saw me staring at you white-knuckled and struggling to find words, I am sorry, yes, you are “one of them”.

It is not all ashes and debris all the time. I have met some great people in product management and marketing. I tend to cling to the good ones; they are deserving of my company. Especially when I can find the ones that understand one of the core principles of software development that is unspoken: You should always be throwing away your source code.

What madness is this you ask? Calm down. Breathe. Let me explain. Yes, I understand that there was a few million dollars or more invested in making “a thing”. Honestly, though, software development is not like building houses in a subdivision. There may be somewhat of a blueprint, possibly an architecture, but often software development is a steep descent into the hell of managed chaos, where people create staggeringly intricate connections between objects of increasing geometric complexity, often running into issues that were unforeseen.

Sometimes even people will get their product stood up and in front of customers before the geometric complexity manifests itself. Suddenly, the servers may go down, Product and Revenue will start to be Impacted. Of course this agitates the high priests and suddenly making sure this gets fixed becomes The Top Priority. It goes without saying that The Top Priority is still to make sure that all the other Top Priority items get taken care of too. Someone declared this code Complete, remember? And this is where we get into the big bucks part of the equation. Software developers are often required to make complicated trade-offs in order to serve these interests. Of course, this-is-the-way-we-do-things.

Is there an alternative? Let’s discuss.

The reason we got here in the first place goes back to that whole geometric complexity thing. Software development is challenging and trying to make sure we can manage all of the risks and the unknowns is never perfect. Yes, that is correct; software development has the unknown unknowns. We build many things and sometimes there are things that are not well communicated, and sometimes there are things that are not well understood. The sum of these things results in imperfect systems being created. How often does this happen? Only on days that end with the letter “y”.

There is some sort of zeal or enthusiasm for people to be able to create cookie cutter software magically the same way that you build houses or the same way you create store-bought stuffing. Gather the team, the ingredients, the blueprint and go. Over time, a well-run team may get to the point of having almost no new unknown unknowns while adding features to a software-as-a-service platform. To get to the point where this is a stable and mostly repeatable process takes more than one year. Does it take two? Does it take five? Quite often that depends on whether or not people are quitting, or dying for that matter, spiritually or actually.

Team stability is probably one of the most unappreciated things I run into on a daily basis. Now it is time for me to bring the point home about throwing away your source code. By the time I am done explaining, I am expecting you all to nod in amazement and wonder; I also expect a five star Yelp review.

Through the years of managing teams and shipping products there always comes a moment after a piece of software is built that a team member comes up to me and is agitated. They want to refactor something. 

Refactor? That is a scary word to the high priests of marketing and product management. It generally means random engineering tinkering under the hood that does not come with a Change Request. It may not be clearly attached to Quarterly Revenue, much less to Roadmap.

Sometimes the job of engineering leadership is to give that poor gentle soul a hug and a reassurance that everything will be okay; that this is not the hill to die on. Sometimes, that engineer will come back a few weeks later, more visibly disturbed. They need to fix something. It will go from “this is an inconvenience” into “this is a time bomb” with varying degrees of speed. Do you fix it? Do you forget it? It is not always clear. Sometimes you get the bear. Sometimes, the bear gets you.

It is important to set aside time for this clean up work on any project. In video game development, especially for a brand new game, I make it very clear up front that prototyping work is intended to be 100% throw away. This is important. You have to take stuff and throw it away. Do it over. Do it better.

We learn things in making software, we build things to test out hypotheses. It is important that this research and development work gets its properly allocated share of Research. It is important that it leads to time to do additional Development. Quite often people will consider The Research as The Development. This is a dangerous, deadly, dark path. Just because someone has written a thing, you must not necessarily assume you should ship a thing. The amount of cartoon stink lines emanating from it may vary.

Fighting the fight to refactor code, and to throw away code that-must-not-be-shipped is a significant struggle and super important to the stability of your team.

The more luxury you can afford your team to go and do the good work of making sure they have the best code possible, the more likely you will end up with the best product possible. There may or may not be studies on this. My empirical data on this has made me a firm believer; I carry this torch and shield with extreme vigor.

Long term, if you can fight this good fight, even if you lose it from time to time, your teams will stay with you. They just want to do their best work. They want their best work to be respected and appreciated. What happens next? You will continue to see them delivering their best work again and again. When people are on a team like this, it is the greatest feeling imaginable. I was on a team like this a few times and I miss it so much it hurts. It is why I am in the process of building a team like this right now.

However, if you sacrifice your teams on the altars of Roadmap and Revenue, I have some bad news for you. This will murder the gentle delicate souls of your best people. It will crack their insides and deaden them to the feeling of joy. Invariably, it leads to people considering the insidious whispers of Recruiting. You heard me correctly. If you do not give your knowledge workers the space to “work” with their “knowledge”, you must understand that they will want to leave.

I went through this whole article trying to avoid the words Refactor and Technical Debt. I was mostly successful. These are the words that engineers use when they feel The Light die a little; these are their impassioned pleas to the monocle-wearing cloud-people in leadership that they want to feel joy again, to breathe and be free. These words become dirty to the high priests within The Company at the peril of your team; when they become part of the Doctrine of Next Sprint, and that Next Sprint never comes, your best people will promote themselves to the lofty title of Not Working Here Anymore. Congratulations! You have earned a rank of Churn! This Churn will affect Roadmap. So we will need to replace them with new people. These people will likely not have all of the skills and experience needed to thrive on day one, many of them will take time to get ramped up and acclimated to their new world.

Of course, since the people who wanted to clean up their code so badly never got a chance to, this next generation of knowledge workers that comes in finds themselves neck deep in a world that is filled with brokenness and hurting.

This starts a vicious downward spiral of decreasing code quality, and it is a sadness in the hearts of all who behold it.

The best code bases are made by the best teams and the best teams get the luxury to rewrite their code bases when it is necessary. To deny your teams the ability to have the best code bases you will no longer have the luxury of the best teams.

What you wind up with is a code base that does not age well, and a handful of people who feel obligated to maintain it until such time as it can be taken out behind the shed and put out of its misery. If it is code in a successful product, this is a process that can take years and is horrifically painful for everyone involved.

Just about every software system needs some level of rewriting. If it is good code it may not need much, if it is bad code, it will need quite a lot. The question is, do you want to make the time to rewrite the bad stuff when you want to rewrite it? Or do you wait until the time arrives when you urgently need to rewrite it? The number of people who wind up doing the latter may totally shock you!

In conclusion, I boldly state it is important to let your people throw away their code. Do it over. Make it better. Throwing away code improves things in many ways. I am not going to bother to go into all of them in much more detail, because the most important thing about letting people throw away code is that it means you value them as people and you value the whole of your team.

If you need more convincing than that, I honestly wonder if you deserve your paycheck. If you are ever in a meeting with me, I assure you I would be giving you a quiet Greta Thunberg stare with the blazing intensity of a thousand angry suns for the duration of said meeting, and it would be on repeat for all of the meetings we would be required to have together afterwards.

To the rest of you, thanks for reading! I hope you enjoyed this voyage into the thoughtfulness of leadership and the importance of throwing away code!

As always, like me on the socials, share me with the connections, and feel free to indulge in an attempt of creating meaningful social reciprocity.

Those who ignore the lessons of history are doomed to repeat them. I guess that sounds really smart. Sometimes, we are doomed to repeat things regardless of whether or not we learned from history. Obsolescence of content platforms is the ripe and juicy fruit of deliciousness for today’s random extrapolation of thinkery.

The inevitability of a platform becoming obsolete feels like a thing to me. I don’t know that we have some sort of clever Moore’s Law around it and it has happened for every single platform out there. Whether you are downloadable casual games, mobile 1.0 feature-phone games, or even flash-based games in the browser, you had a black-swan moment when eventually someone said “hey the party is over” with their wallet, and your revenue went to zero. In the casual-games downloadable space, the last blow was struck by the sudden flood of hidden object games that crowded out all the other content. Ironically, no one saw the hidden object game crisis coming.

This is a natural phenomenon. It happens without fail every five to nine years. Each platform has its moment in the sun and then gets its place on the boom-bust market curve. What keeps me fighting the good fight is the fact that every boom cycle always is more biggerer than the last bust cycle. If you accept this as a reasonable hypothesis, the forward thinking person asks “What about modern day mobile 2.0 app stores?”

I believe they too shall pass. We are seeing the struggle mounting even now by companies like Epic Games, who are suing Apple and Google to break the monopoly on their respective ecosystems. Certainly this platform is backed by some of the biggest companies of today. But that was also true the last time around. Carrier-based game decks had every carrier as a giant corporation behind them; and the casual downloadable games portals were backed by some of the biggest internet companies. So if we accept that in content, there is no such thing as “too big to fail”, then what does that mean for tomorrow?

If we could magically answer this question, we would have some super serious cheddar in the bank. I cannot magically answer this question. I also may be intermittently lactose intolerant, so who needs all that cheddar anway. Also please put your cheddar in the fridge.  I digress. For the coming App-ocalypse I am not going to be able to choose the form of the destructor. I can only try to convince you it is coming based on the past history of all the digital content marketplaces ever. So again I ask: What does that mean for the world of tomorrow?

I gave a super random talk in Seattle many years ago called “Out of Touch, the Next Big Thing after The Next Big Thing”. It was a clever presentation on gesture technology. It may have something to do with my old-person dislike of touch screens. I still do not forgive you all for being accessories to the second-degree murder of the Palm Pre; I loved that phone. It has everything to do with what is next, or even what is next after whatever is next. I was greatly appreciated by a handful of UX researchers in the audience. I could tell that almost everyone else in the room was not interested in talking about stuff that far out; most of them were just trying to survive until the free beers at five pm. So let’s talk about What Comes Next. For realsies, this time.

There were a lot of people who jumped onto the VR hype train; I know I did. The dreams of being able to strap a bucket to your head and be transported to amazing destinations without being crowded into a Southwest Airlines middle seat were very seductive. It seemed like we were there with graphics processing technology. I jumped in. Unfortunately, dear reader, the problem is that I did not pay enough attention to the fine print. Let me restate that for dramatic effect. The problem was not that I did not pay attention to the fine print, the problem is that I simply couldn’t. Trying to read text in VR is like trying to play pool with a rope; it is a pretty fruitless exercise. While we have the graphical capability to show cool stuff to users with a bucket on their head, the problem was in the rendering capability of the screens that were strapped to your eyeballs. Reading text in anything other than garish preschool lettering and fonts was a near impossibility. The hype train had already left the station unfortunately. It would have been great if someone could have addressed that issue before it got as far as it did for consumers. The whole thing, for lack of a better phrase, failed to deliver on its vision.

I hate to be the person to scratch out VR for the consumer masses; unfortunately I am not able to reach any other conclusion. I do not think it is there. I do not think it will be there with the hardware that is currently in super secret labs around the world. I apologize for the deception here. I know I said I would talk about what is next, not what-is-next-after-what-is-next, nor what is not next. I am a confusing creature sometimes.

Now that I have beaten your expectations senseless with a shovel, let’s finally make The Prediction. Before I do; I have to declare,  for total transparency, that I have a fancy cooked-meat dinner riding on The Prediction. You heard me correctly; there is something at steak here.

I think that the next major platform is going to be Augmented Reality. I believe we are not quite there yet, because there are still a few technical problems to solve. I also think that the black swan event that eventually craters the mobile ecosystem is a few years out. The Epic lawsuit against Google and Apple may play into that. The Hyper Casual publishing phenomenon is a likelier crater of impact, or the fact that the number of incumbent IP at the top of the channel continues to accrete years of existence. At a certain point of age, the enthusiasm for “rehashed previously enjoyed” content will turn into yawns and swipe-lefts. The indescribable hunt for cool will drive consumers and trendsetters elsewhere.

So we have unsolved consumer technology problems, and we have no real clear idea of what “this is totes not adorbs” will look like. Hardly a compelling case for the end-of-times for the app store; at least in the next five years. I do think that both of these boxes will be checked by 2025 at the earliest, and by 2027 at the latest.

It is not clear to me if the form factor for next generation Augmented Reality is going to be a transparent hand device, a set of glasses with a small processing unit wired into it, a funky visor, or even just some sort of snazzy data projector on your wrist. It could even wind up being the dashboard on your car, at this point. I do believe it is coming in five years and it is coming for your phone and your in-app purchases. You should be very afraid.

The other thing that is not clear to me is the form of the platform defining content. Every platform has it. When you say “cd rom” people think “Myst”. When you say “sound blaster” people think “Wing Commander”. When you say “Nintendo” you probably even add an accent when you reply “Its-a me! Mario!”. Generation 0.1 of mobile had Nokia Snake. The current generation of mobile games have Supercell’s smash hit Clash of Clans as its genre-defining hit; possibly even Candy Crush could be considered as a class equivalent even though it is not gamer-focused like many others. You might buy a phone just to play Clash of Clans; you probably did not buy a phone just to play Candy Crush. You sure as heck installed the crap out of that game. I will bend my own definitions of platform-defining content so you do not feel guilty for swiping those sweet, sweet candies.

The biggest thing that will drive the adoption of AR is going to parallel the thing that drove smart-phone adoption for content consumption: price and convenience. I am concerned that it will be nebulous and tepid for content, despite how cool Pokemon Go looks. Pokemon Go did not prove that AR is an accessible platform. Pokemon Go proved that Pokemen does not release enough expansions and content to appease its rabid fan base. If you doubt me, ask why you no longer see crowds of Pokemon hunters on the piers of Santa Monica anymore; at its peak it was up to 1 in 3 people by my own personal estimate. Now it is as hard to find as Reebok high tops, and Trapper Keeper binders. C’est ne pas une fad.

This frightens me as a content creator and lover of platform-defining hits. I do think that everyone is getting ready to toss their increasingly-more-expensive-phones with increasingly-watered-down-content-offerings. They stopped making them smaller; it also feels like they stopped making them better beyond annual incremental technology upgrades.

I think we are just about ready for a world where we get a shiny new device. My belief is that its killer app will be to superimpose the best BOGO or discount offer on a cup of coffee just by peering through it. Heck, people may just want the time arbitrage of knowing where the shortest line to that sweet sweet cuppa joe is hiding. 

Sometime after we are all peering into our phones to save five minutes or five dollars as we do the hokey-pokey and turn ourselves around, a random content developer will inject a big enough dopamine hit by accident that everyone will want to get one. We will all tweet and snip-snap our newly discovered chemically-induced rush, and a new content platform will be born.

So there you have it. My money is on 2025 being the year this product comes to market, even if I do not have all of the details. If I am wrong, I owe a steak dinner to someone. If I am right I am going to do a little victory dance after the first mouthful and I shall ask my friend, or perhaps some random passerby, to film it for your viewing pleasure.

And now that you have read my brief glimpse into the future, I encourage you to follow me on the socials. Twitter, Linkedin, RSS Food, whatever you do. In five years time I hope to dance for you. I cannot say it will be a good dance, but I will enjoy it greatly; I firmly believe that I will win this bet.

It is really easy to look at Facebook and Google and Netflix and think “Yeah I could have built that.” Every one of us has one or two or possibly even three ten-billion-dollar-ideas. All you really need is a programmer right? This startup thing does not look all that hard.

I just happen to be a programmer. It is kind of frustrating to talk with people and see the hunger in their eyes because I am their path to Zuckness. They haven’t even busted out the unilateral NDA for their amazing idea and I feel dirty and used. It breaks my little heart.

The good news though, is that I am kind of crazy. All my non-crazy programmer friends send me lots of people to talk to; for some reason they are not interested in talking to idea people. I like talking to the idea people quite a bit, honestly. Does that mean there is something wrong with me? Maybe I should seek help. Maybe not.

Through these conversations I have learned that people do not have any idea how hard it is to make a startup, nor do they have any idea how big numbers work. A good friend of mine lamented that they have been doing high tech startups for twenty years and they were not yet abundantly wealthy. It does not work that way. There is no reward for time served.

In the process of trying to help people to build their startups I have learned some interesting things. I am going to share some of the more obvious things you can do in order to help increase your odds of long term success.

The first thing is that there is never enough money to do everything you want. You are going to have to make sacrifices to get to the starting line. Deciding what you can and cannot have is crucial, and will test your limits mightily. Most of the time that someone comes to me with an idea, it is generally a five hundred thousand dollar startup. Usually they have about fifty thousand. That is not a giant gap in Carl Sagan terms. There are ways you can save money in getting out the door; we will go through them.

Students – You can generally get away with a more junior programmer than you think you need. The challenge is that you likely will need to give them some kind of direction, or else be prepared for a more expensive rewrite later once you have de-risked your research in development. It is gut wrenching to be on a phone call with someone who has their cost per user climbing 3% or higher for every five hundred users they are adding, when they have found a solid product market fit.

Part Time Programmers – In addition to students, you might find someone who already has a steady job and is willing to help you on some kind of equitable basis. They may love your idea, they may need your product, and they might even be willing to work for revenue share on the backend. Be wary of the person who wants to work entirely for free; you often get what you pay for.

Overseas Operations – You can generally find less expensive developers outside of Silicon Valley, as shocking as that sounds. You can get some pretty good bang for the buck by going overseas, or even to Canada. Sometimes you might find a marginally more expensive outsourcing firm that has a local handler to work with you on getting your idea built. There are risks here too. It is hard to know if you are funding an eventual competitor, or even if you are going to get everything built according to the letter versus the spirit of the agreement. Many of these companies are building products as a work-for-hire mercenary business to get to some goal as an organization; either they are looking for bigger contracts, or they are just idling along profitably as a think tank looking for product market fit.

The Crazy Full Stack Veteran – This is the person who has done this dance before and generally works at a 10x pace. Usually they are a lone wolf and have enough of everything you need to get something stood up. There are some interesting trade-offs to consider with the full stack veteran to get your idea to market.

These all have their pros and cons. There are approaches that are cheaper, that will take more time. There are approaches that have less risk, but will cost more money. Balancing this all will be hard, especially since most people are very adamant about the role of cash in all of this.

When you are cash poor for a good idea, it is worth trying to understand what you can and cannot give up in order to get the burn rate down. Are you willing to give up revenue share to get out of the gate? Are you willing to give respectable amounts of pre-funding equity to your developer? Do you have to own the technology developed? All of these things can be used to bring your up front costs down.

When I talk with people about their ideas, I tend to size them up like an investor would. Have they managed businesses before? What level of experience do they have with success? If a person has a nice idea and is fresh out of school, the ROI on equity for your first shot out of the gate is essentially unmeasurable for upside. If you are speaking with an executive with twenty years of experience with hundred-million-dollar enterprises, that is a safer bet that their equity will be worth something. You can generally set your own expectation on returns after spending time talking to people and looking at the marketplace.

If you are able to front some of the development cash, and then pay the rest out of revenue share, that is also an option. If the work costs fifty thousand dollars worth of time, and you can only pay twenty up front, it is reasonable to offer twice the amount of the gap on an accelerated revenue share until that gap is paid up. I like this model. I have been partially paid out on it in the past, although it is a calculated risk. When I do these things for myself, I generally cap it at twice the amount. It is not fair to burden someone with perpetual accounting for revenue share on a pure cost basis.

Finally, do you need to own all of the technology? I like to own my frameworks and I have built about half a dozen projects over the past decade where I retained the rights to research and development work. I am always willing to sign a time limited “non-compete” on that technology, usually six months to a year after the completion or termination of the agreement, depending on the product space, the size of the deal, and the people involved.

These are great tools to align the costs of your product. You can mix and match them too. I think that there is good value in having a part time technical executive spending a few hours with your students or overseas developers to make sure that you are getting the right things done. Be prepared to make it worth everyone’s time. For me, I like to have a slice of equity and a slice of cash for helping people; it is never fully worth it to do one or the other.

Now that you have gotten past the benjamins, let’s discuss some things to help you make sure you are getting your money’s worth, and building value. Let’s talk about legal agreements and what you should make sure you have access to.

Regardless where you found your happy little worker bees, make sure you have a proper agreement in place; what you pay in lawyer fees now will save your business in exorbitant costs and pain later on. Make sure you have a reasonable jurisdiction in the agreement. Make sure the terms for confidentiality, termination and breach are all mutually acceptable. Understand if you are going overseas that the intellectual property laws may differ. Also, please do not just ask people to sign a unilateral NDA just to discuss the idea. It makes sense when you get into specifics to have a mutual non-disclosure agreement in place. You probably think your idea is priceless. The average programmer will tell you without execution it is worthless. The real answer is somewhere in the middle.

As you get your agreement set up, try to establish incremental milestones; this should be pretty common. Be afraid of large lump-sum payments. It is fair to put a milestone on contract execution, and to add milestones for feature completion, QA completion, and final product acceptance. Make sure there is language in the agreement to discuss “out-of-scope change requests”. When milestones are submitted for acceptance, you should commit to a “yes/no” within a reasonable period of time. When I ask people to build projects by milestone and I am unable to get to it within ten business days, I commit to approving the milestone For Billing Purposes Only to keep the cash flow going. It is only fair to all parties.

Make sure you are getting access to the things you are paying to have built. If people are building you a product, it makes sense to have source level access to the code repository at all times. I am saddened when I hear about people holding source code hostage in startup situations, regardless of the circumstances. If you are working with someone who is nervous about giving you access to the things you are paying for, you should consider that a warning. A good technologist will rebuild a second version of something from scratch better anyway. If they are not comfortable giving you repo access to code for the product, you should walk away. This should also mostly be true where you are sublicensing code from them instead of buying it outright. The only exception is if they have something in escrow, or clearly being used as a provably-successful revenue-generating enterprise they wish to protect. If this is the case, make sure you bake in a year of time into any termination for them to keep your business running as a moral part of your agreement, so you do not get shut off and left completely in the cold.

There are some things to think about as you are building your billion dollar business. There are always ways to get stuff built; there are always tradeoffs to be made to get in front of customers. These steps will not greatly enhance your incredibly low odds of success, but will help make an already difficult journey more reasonable and manageable.

As always, feel free to like and/or comment. I have done my best to help some people live their startup dream. I am always happy to answer questions!

One of the best things about being in management is dispensing wisdom, especially to very unwise people who despise the fact that your job is really necessary. I take some painful joy in helping people like this. I know the instant they have extracted what they needed from me to help them be more successful, they immediately go back to the watercooler and talk crap about me. I hope you all enjoy it, you ungrateful monsters. 

When people come and ask for help there are a lot of different tools in the chest to provide them with help. I prefer to teach people how to get themselves out of their own messes than doing all their work for them. I am very fond of the fisherman metaphor and have used it to explain why I, as a teacher, do not just give all the answers to the test immediately.

“If you give a man a fish, you feed him for a day. If you teach a man to fish you feed him for a lifetime.”

Everyone agrees this is profound and clever. There is often an aha moment for some people when they realize that what they are trying to do is analogous to fishing; dripping bits of wisdom like this onto people helps augment the mystery and power of leadership. It probably buys me about five minutes a week of reprieve from crap talking by my detractors at the watercooler. Even if it does not, it is still a “go to” for me.

The problem is that I really have it slightly wrong. I came to that realization after watching other people’s behaviors on the topic of hungry people and fishing.

It is sometimes too easy to shove someone away from work and just take it over. It is pretty brutal to do that to one of your own direct reports honestly, and it should be a tool of last resort when there is urgent business need. Generally you want to coach people to find the nuggets of wisdom they need to identify that the monster driving people out of the amusement park is really just Old Man Jenkins the Janitor. Scooby Doo mysteries have nothing to do with fishing; let me get back to my point.

The challenge with teaching people how to solve their own problems is that it is hard and time consuming. It requires skill. It requires tools. It requires super duper serious patience.

All of those things are hard to come by, plus they are usually not the things that got you into your leadership-and-or-management position to begin with.

What the hell though, you are knowledge workers, right? Figure it out.

So I want to give you my restatement of the fisherman’s parable.

“As someone who is responsible for feeding others, if you don’t teach people to fish as fast as possible you will both choke to a super stupid death on fish.”

I admit, it is not that elegant. It is rather poignant. I see people choking themselves and their teams to death quite a bit. My sage-like advice on this subject is pretty basic: 

“Hey! Stop doing that!”

You have to invest some time in learning skills to teach people in a leadership or management role. Everyone has different methods that make sense for them, and there are different methods beyond those that may make more sense for the person trying to learn. I do not have a degree in teach-ology to give some advice here. I know what works for me and I know when I have to adapt those tools because someone else is choking to death on fish.

Similarly, you have to build, buy or steal tools to help with teaching. This can be collaborative documents, repos, code-along tools, or just standing behind someone with a clipboard asking smart questions. That works for some people, astonishing as that may sound.

If you do not make time to do those two things then invariably the people you are not teaching well are not going to learn well, and also they are not going to get their jobs done.

If they are not getting their jobs done and things get serious, you are going to have to do some of their work when no one is looking. Hint: This is addicting, some people like getting paid to let other people do their work for them, be very very careful of this kind of behavior and avoid making it a default.

If you create a situation where you are not teaching people the skills they need, and additionally you are carrying them over the finish line, then you will have a problem come End Of Year Review. Even if you are a 10x engineer and capable of doing amazing amounts of super cool work, the suits and bean counters will sniff you out; breaking your back does not scale. Plus, the shareholders resent the hefty carry.

Eventually the day will arrive and you will get “gently told” to be an IC, or perhaps “less gently told” the company is going in a different direction (that does not include you). At that horrific moment, you will realize that you have just choked yourself, and probably a few other people, to death on fish.

PS: I really like fish. I also like the clicks and the likes and the hashtags and the socials. Eventually I will figure out the Magic Words To Be The Viral!