The Misanthropic Developer

Nobody Works Well Under Pressure

November 14th, 2022

You hear a lot of people saying that someone works well under pressure, or companies posting job descriptions that include the requirement that applicants work well under pressure.

The truth is that nobody works well under pressure. Period.

Someone may work better than a random sampling of people when put under pressure, but that’s not the same thing.

What most people consider to be “working well under pressure” generally comes down to three things – training, emotional detachment, and luck.

Training

It’s a common saying in the social circles of people who operate in high pressure situations (think special forces, EMT’s, etc) that “People don’t rise to the occasion. They fall to the level of their training.”

Pressure doesn’t bring out “the best” in you. It shows what you’ve been learning while you weren’t under pressure. It’s why you have so much repetition in training for the military or in martial arts. If you do it often enough, it’s more likely to become “second nature” – sometimes to the point of being ingrained as a spinal cord level reflex.

That’s not to say that you will do it nearly as well under pressure as you do when you’re training, but that training makes it more likely that you’ll at least be able to do it at all.

(For those of you who think otherwise, the United States military makes manuals for pretty much everything that you might have to do in the field – partially because they know how likely it is that people in the field will freeze up or forget their training).

Emotional Detachment

There are a couple of kinds of emotional detachment that I’d like to cover here.

The first is a form of emotional detachment where you legitimately don’t really care about the person or situation that’s causing the pressure. It’s caused by a lack of empathy and usually isn’t healthy for either you or the people around you.

That’s not to say that you have to care viscerally about every situation that you land in, but if you don’t care about them at all, that’s generally a really bad sign.

The other form of emotional detachment is an active choice (and often involves training to get to that point – imagine that).

It’s the ability to take a breath, step back emotionally from something you would otherwise be very invested in, and focus on now. You take the short-term action of actively ignoring the past, focus on the space right in front of you, and dedicate yourself to getting through the next five minutes because the only thing that exists at this point is right now. And then you keep doing that until you’re out of the crisis situation.

That works for very short-term situations if you can pull it off. For longer term situations, you set a goal to reach and then reassess (I’m going to keep going for 3 miles, then I’ll eat. After you eat, you have the energy to keep going and you set your next, fairly short-term goal. Lather, rinse, repeat).

Afterward, you give yourself the time and space that you need in order to fall apart and process everything that happened. It’s a sort of short-term loan that often comes with heavy interest. I speak from experience.

Luck

The last item in the list is both the most overlooked as well as usually one of the most important.

Luck plays an outsized role in what we do on a regular basis, but it plays an even larger role in high stress or crisis situations.

You can only control your own actions, and if something happens that doesn’t line up with what you’ve done, the entire thing can come crashing down.

During normal situations, you can more easily come up with a decent response to things not going your way, but during a high-pressure situation, it’s much much more difficult for you to respond to the unexpected.

You cannot plan for the unexpected. You can only prepare to be surprised.

In a high pressure situation, your ability to effectively cope with surprises is reduced drastically. A lot of the people who get praised for “doing so well” under pressure got incredibly lucky. Don’t let anyone try to convince you otherwise.

What should we do instead?

Given that nobody works well under pressure, what should we do to make sure people do work well?

The answer to that is fairly straightforward (though sometimes difficult to actually accomplish) – you work to take away as much of the pressure as is reasonably possible.

If you’re leading a team, provide them the cover and psychological safety that they need to do good work. Reassure them that mistakes will happen and that they aren’t going to be taken to task for things beyond their control.

Don’t get me wrong, this is an incredibly difficult thing to actually do because it requires not only that you reassure your team, but that you push back against the people above and to the sides of you in order to make it more than lip service. It is, however, a sign of real leadership.

I know that some people are going to say “that’s great for production going down, but what about ‘real’ high-pressure situations?”

The thing is that it’s true of both the office and in crisis situations where lives may be at risk.

One of the first things you need to do in order to get a group of people out of a life or death situation is to calm them down because panicked people are prone to make even more mistakes (and that’s if they don’t completely freeze up).

You get their attention, calmly convince them that everything will be okay, and then focus on getting them out in one piece (you often have to reiterate that things will be okay during the process of getting them out of the situation). It’s a lot more difficult than that makes it sound, but that’s what it boils down to and the reason for that is that the stress/trauma response of most people tends to follow a few patterns no matter what causes the stress.

That’s not to minimize the stress caused by life or death situations – just to point out that, no matter the source of stress, people tend to respond similarly. That’s also something I can speak from experience on.

And if you don’t believe my experience, how about former FBI hostage negotiator, Chriss Voss? You’ll find references to similar tactics (as well as the fact that these responses occur in situations no matter what their cause) in his book Never Split the Difference and in a number of his talks.

Whether it’s in the office, in a medical emergency, or other crisis situation, people don’t work well under pressure. Do what you can to lower the stress levels and give them the tools they need to actually succeed.
Cost Centers vs Profit Centers

November 6th, 2022

In a lot of businesses, you have two areas of operation – cost centers and profit centers. They both have an impact on the profitability and viability of a business, but they are often viewed very differently by the people who run the business.

Where it matters to most of the people who read this is that working in one vs the other can have an impact on your career – both in terms of pay, recognition, promotion, etc. at your current job as well as what sort of attention you get from companies for future jobs.

So, what are cost centers and profit centers and how do they impact you?

Profit Centers

Profit centers are where the money is made. The one that comes to mind immediately for most people is sales, and that is indeed a profit center. Another example would be the Asset Management and Wealth Management departments of an investment bank (yes, there is a difference between these two things, they are often separate departments, and the amount of money generated there for the business is absolutely unreal).

Profit centers tend to get most of the attention from the VP and C-level employees of a company, because those people are usually focused on growing revenue year over year. That means that they want more sales.

Additionally, the majority of upper level leadership in most companies is going to be composed of people who came up through profit centers, so this becomes a self perpetuating cycle because most people value what they know and understand over what they don’t.

Notice that I said growing revenue and not increasing profitability because these are two completely different concepts but the differences between them is outside of the scope of this post.

Since most of the business’ focus is on profit centers, the people who work in them tend to have a much higher visibility. They get paid more (on average), are often promoted faster (partially because they have higher visibility and partially because they can quantify their impact more easily), and are generally the last people impacted by layoffs (after all, why would you lay off the people bringing in money).

Working in a profit center also means it’s generally easier to get an even more high profile, higher paying job with a more impressive title at another company after you leave your current one. Part of the reason is that you can put things like “created software to increase annual revenue by $x million dollars” or “lead team on project which opened up core services to new markets, leading to a 30% increase in revenue” on your resume.

That sort of thing makes a lot of companies and managers drool with anticipation of what you can do for them because you’ve proven (or at least claimed) that you’ve done something amazing in your current/previous positions that grew their bottom line.

I’ve said it countless times before, businesses and hiring managers are often severely lacking in creativity when it comes to seeing potential in people. They tend to stick to type casting people as only being likely to do similar things to what they’ve already done. This is something that you want to think about as you chose jobs throughout your career.

Cost Centers

Cost centers are usually viewed as anything that doesn’t directly bring in revenue. All of the stuff that keeps the lights on – SRE, infosec, and pretty much anything back of house (unless, of course, you’re talking about a business that sells those services to other businesses. If that’s the case, they’re a profit center because they’re bringing in revenue).

Businesses usually try to spend as little as they can get away with for people who work in their cost centers. Don’t get me wrong, they try to control the salaries of people on the “profit” side of the house too, but they do it with the understanding that they’ll lose those people if they push too hard.

They’ll also try to spend as little as they can on keeping up with current practices in areas that they consider to be “less important”. All of this adds up to problems for your career.

That’s not to say that you’ll be getting paid badly or that you’ll have problems finding your next job, because that’s not the case. It just means that you won’t be likely to have the same salary or recognition in regulatory technology as you would with the same skillset in asset management in a mega bank (I speak from both observation and experience).

Unfortunately, it also means that you’re more likely to face a layoff during an economic downturn (or because the CEO decided to make the short-term numbers look good so they can sell off a bunch of their stock after having it go up due to decreased head count).

So, what can you do if you’re located in a business’ cost center?

If you’re looking to stay within the company and advance, take a serious look at moving to the profit center side of the house.

Ever notice in large companies when a Director or Vice President of a department makes what seems to be a lateral move within the organization? The reason is usually that they’re moving to a higher profile, more respected part of the company – frequently from a cost center area to a profit center one.

When you get to that level in your career (and ideally long before you get to that point), a lot of your career decisions are strategic so that you can be better placed for larger future gains.

One example that comes to mind is when the director of Legal and Regulatory Technology (the department that I was in) was hired in from outside, ran the department for about a year, and then immediately moved into either Asset or Wealth Management. On paper it was a lateral move, but in reality it was a promotion because it meant that he was in a much higher profile position and was more likely to be given larger titles and much larger salaries in the future.

You can do the same thing. Get to know the people in the profit center department that you want to move to and, once you have people in your corner, put in for a transfer. We all know it’s easier to get hired into a company when you know people inside, but moving between departments is often ridiculously simple when you make friends with your future co-workers and boss while you’re already in the company.

If you’re looking to move outside the company and want to move from a cost center to a profit center, start looking for ways to quantify the financial impact that you’ve had while doing your job. Honestly, you should be doing this anyway (because your resume is a marketing document, after all), but it’s especially important if you want to move into a different type of work.

Did the work you do lead to a measurable decrease in costs for the business? Did it lead to decreased time required for the business to generate profit? Did you lead an initiative that had a material impact on the business that you can spin as more than just “we kept the lights on so the sales people could do sales”? In the words of a coworker of mine, HYPE THE HELL OUT OF THAT.

Start talking to other companies while you’re still employed if you can. If you find that you aren’t getting the traction that you’d expect in your job search, consider making a fairly brief team change within your company so you have a title on the profit center side of the house even if most of your accomplishments were on the cost center side, because that may help (3-6 months is often long enough if you can score a win or two while you’re there).

If you’re going to be type-cast (and you probably will be), do what you can to control the narrative so that you can have some influence over how you get type cast. This is your career. Don’t let others write the entire script on your professional life because, if they do, they’ll do it in a way that only benefits them.
Slack Time

October 31st, 2022

A lot of bosses and companies try to squeeze every ounce of productivity out of their employees that they can. Some of them even try to guilt, coerce, or demand that they work overtime on a regular basis.

The irony of this is, not only are they not getting more done, trying to force total efficiency or extra work is actually setting them up for failure and, possibly, for catastrophe. In addition, aiming for 100% utilization is impossible anyway.

The alternative to this is to build slack time into your schedule. I realize that this is heretical to a lot of people (including several former bosses of mine), but it’s an incredibly important part of being less reactive and more proactive (or, put another way, being less tactical and instead being more strategic).

So, what the heck is slack time anyway?

Slack time isn’t just sitting there, staring off into space or spinning around in your office chair (despite what my former bosses have believed). It’s time when you do things other than work on features for your project, and it can take many forms. I’ll go over just a few of them here.

Professional Development – You should be setting aside some time every week for your people to learn new things. Whether it’s watching a video, playing with some new tech, or a number of other things. Learning is part of their job and this needs to be realized and acted upon.

Strategic Planning – Both you and your people need to take time to look at the bigger picture of the things you’re working on. Among other things, you need to stop and think about why you’re taking the actions that you are and see if there’s a better way to reach your business goals.

I can hear several of my former bosses start to claim that it’s their job to think strategically and the developer’s job to do as they’re told. I’d like to take a moment to tell them how wrong they are and point out the damage that they did to the projects by taking this stance.

Paying Down Technical Debt – Technical debt is sort of like monetary debt. If you don’t pay it down, the interest it generates will kill your project by making it harder to make changes to the code over time. That “really quick fix” that you put into place to fix a production bug or “easy feature” that you shoehorned into a class that wasn’t meant to contain it makes it harder to modify the code. If you do it often enough, it makes it almost impossible to modify anything without breaking things.

Ideally, your team should be doing some work to pay down technical debt any time they work in a section of codebase, but if they feel pressured to always do more, this often doesn’t happen. Sometimes you just have to set time aside specifically for paying down some of the debt.

Improving The Working Environment – No, I’m not talking about upgrading the chairs in your office (though if you have the budget and, for some reason still have people in a physical office, go for it. It’s worth every penny).

Spend time to improve the tooling that you use as a team. Don’t have a CI/CD pipeline, build one out. Don’t have monitoring in place, start working on it. Don’t have your logs aggregated so that they’re easily searchable, allowing you to spot trends or find problems without logging onto a physical or virtual machine (yes, there are still companies that use physical hardware and standalone style VMs), look into ways to get that in place.

In short, make the lives of your people easier. The less time they have to spend fighting the tools and processes that are holding them back, the more value they’ll be able to deliver to your business.

I can hear you going “you know, some of that sounds really great, but it sounds like it’s going to take a lot of time away from actually doing work.” The truth is that each of the things that I’ve listed is work, and they are all vitally important to your business being able to continue functioning. Unless your business is a quarter away from insolvency, then it behooves you to do these things and that requires that you stop trying to be “100% productive.”

Also, remember when I said that not having slack time can be catastrophic? If you work your people into the ground as a feature factory, when (not if, when) you have an emergency, you’re going to be dead in the water because your people are going to be so fried that they can’t think straight. The above items can even help prevent catastrophic emergencies because you might be able to catch them before they happen.

So, just how much of your team’s time should be “slack”? In my experience, about 25%

Yes, I realize that it sounds like a lot, but realize that there have been studies that show people only have about 4-6 hours of productive work in them per day anyway, so they’re already taking slack time. The only thing is that they’re not using it well and are, instead, pretending to work so you’ll get off of their backs.

It won’t happen every single week because sometimes emergencies do happen and sometimes there is a make or break deadline, but those times should be rare.

A couple of hours (at least) a week should be set aside for your team’s professional development. The rest of the “slack” time should be split between the high-value work of the other items above (or similar).

Yes, that’s a departure from the Taylorism based management practices you were taught or indoctrinated with, but Taylorism doesn’t work in an economy based on creativity. It was designed for assembly line style work, and honestly, there were better approaches there too.
October 31st, 2022

Happy Anniversary
If You Love What You Do, It’s Still Work

October 23rd, 2022

I was on a panel discussion for a coding bootcamp with an old friend and mentor of mine. While answering one of the questions, he pulled out a quote that’s always made my skin crawl – “If you love what you do, you’ll never work a day in your life.”

I have always hated this saying for a number of reasons. It’s a promotion of the harmful Protestant Work Ethic. It sets people up for abuse and exploitation because it’s used to devalue the work itself and try to guilt the person into working much longer hours than they should all so someone else can profit off of it. It even becomes a form of self-brainwashing where you think there’s something wrong with you because work feels like, well, work.

On top of that, it’s just plain not true.

You can enjoy what you do for a living, but that doesn’t make it any less work. You are doing something, for someone else, to fulfil the wants/needs of someone who is making a profit off of it, so that you can acquire the money you need in order to pay for food, shelter, medical care, and a whole host of other necessities. Do you know what we call that? A job.

Passion has absolutely nothing to do with that arrangement. You’re doing it as a job. It’s work (honestly, even if you aren’t doing it as a job, it’s still work. It’s just a different category of work). The fact that you generally enjoy what you do may make it suck somewhat less to do it on a daily basis, but that doesn’t change the fact that it’s work.

I’ll use myself as an example. I enjoy programming and solving problems that positively impact the lives of others. I’m even generally pretty good at it – certainly good enough that I get paid well to do so. But, at the end of the day, the work that I do on a daily basis is just that – work. It fulfils the needs of companies that use it to make a metric boatload of money.

If I were to win the lottery, yes I would probably still spend some of my time writing code because I enjoy it. However, it would be on things that I choose to work on. At the moment, that would probably include writing code to program robots (which is just plain fun), doing things to solve my own problems, and possibly do some limited work on open source projects that I think are worth contributing to.

However, I wouldn’t do it for 8+ hours a day, 5 days a week. I have far more interests than just writing code.

I’d spend time going on walks and traveling. I’d train more often. I’d do more crafting (I do leather work, woodwork, and used to do blacksmithing). I’d read more. I’d spend more time sitting at the lake and watching the world go by. I’d spend more time with friends.

The list goes on.

On the upside, while I used to hear this saying all the time growing up, I almost never hear it now. It may be that I’m just around a different set of people than I used to be, but when I add that item to the other changes I’ve seen happening with the latest generation, I have hope that it’s because people are finally starting to fight against the exploitation.

Some people would say that “kids these days just don’t work as hard as we did,” to which I would respond GOOD, because they shouldn’t have to. If it’s a sign that things are changing to be better for the average person, I’ll applaud it because it’s been far too long in coming.

The work you do is work. No matter if you “love” what you do or not. You’re doing it because you have bills to pay. Don’t let someone feed you the lie that it isn’t work, because that’s a very short hop away from people trying to not pay you for it while they reap the rewards.
Not Everything Has to Succeed – Death Marches are Bad and Wrong

October 16th, 2022

Over the course of my career, I’ve seen more than a few bosses who insist that “failure is not an option.” Some of them have been on projects I was involved in. Others have been in charge of projects that I’ve had a view on because they were worked on by friends and colleagues.

These bosses act like the thing they are “in charge” of is the most important thing in the world – more important than your health, work-life balance, and pretty much anything that doesn’t cost them directly.

Funnily enough, those same bosses are usually the ones that raise mortal hell if you try to contact them outside of hours. In fact, they’re generally the first people to remove themselves from the on-call rotation when they get control of the tool that manages it.

I had the displeasure of working on one project with an incredibly unrealistic timeline that was short staffed and depended on an outside third party. When I asked the manager what our backup plan was if the deadline couldn’t be met, he had the audacity to say that he doesn’t make backup plans because, if there’s a backup plan, people won’t try to make the deadline (which can’t be met in the first bloody place).

Instead, he ran everyone into the ground, burned out most of the team, lost most of the team to attrition, and still didn’t meet the deadline. Everyone paid the price for this except him. He was praised as a “strong leader” because he abused everyone around him (which is the exact behavior that the managers above him exhibited).

My experience on that project reinforced a very important lesson that I had forgotten for various reasons – Not every project has to succeed. In fact, it’s sometimes a much much better outcome to simply stand back and let them fail. Don’t try to heroically save a project which is going to cost the health and free time of the people who work on it.

Death marches deserve to fail. They NEED to fail, and they preferably need to fail in such a way that the abusers are the ones left holding the bag. If they don’t fail, it incentivizes the behavior of abusive management practices because it shows that they “obviously” work.

(As an aside, I have a friend who once called out my use of the term “death march” until I pointed out the number of people that I know who have literally suffered heart attacks related to overwork. In one case, the CTO came to the hospital and demanded to know why the person wasn’t studying something programming related instead of resting like his doctor ordered. I wish I was exaggerating.)

If you start to see the signs that a project you’re on is going in this direction or that this behavior is expected of the members of a team, remember that you have options. You don’t have to agree to working yourself into an early grave.

I’d also like to point out that, if you see one death march project, that’s a sign that this is how they run most of their projects. Almost no manager or company does this as a one-off. This is the way that they operate because they view it as “how things are done” and because nobody has forcibly stopped them from doing it.

If the project fails, nobody is going to die. If the company folds, you can get another job. You don’t have to suffer in order to stroke someone’s ego or to make a company more profitable.

They are trading money for your time and skill. They don’t own you just because they deposit money into your checking account. Keep reminding yourself of this, because it is incredibly easy to succumb to the abuse and start to see it as normal. I speak from experience.

While you’re reminding yourself that you’re a person and not a “resource,” start working to get yourself out of the situation.

If you just joined the company and your alarm bells are going off, go back to the network of people that you met during the job search. You have an advantage because you probably still have everything spun up. In fact, you may have even had other offers or other positions that you were working on when you accepted the offer to the nightmare job.

Take advantage of that.

For the rest of you, I’m going to give you some advice that many of you may chafe at – with regards to your current job, you should start clawing your time back. I don’t care if you (or your boss) think this makes you a “slacker,” you need to focus on the things that matter.

Take time during your day to upskill on things that you see a market in and are interested in (honestly, your employer should be encouraging you to do this anyway). Network (in person or virtually). Start putting feelers out for jobs that interest you.

Prioritize getting out of the abusive situation and into a better one. I know that will feel like you’re lying to your current employer (and, in fact, it may occasionally require that you do lie to them in order to get out) and that we’ve been conditioned to think of that as bad and wrong but you don’t owe an abuser anything. Keep reminding yourself that you are leaving because they are hurting you (and they are) and that this isn’t just a situation where you simply want to do new things.

Abuse is not normal or acceptable in any situation. Not in your relationship with your family, not in your relationship with your friends, and certainly not in your relationship with your employer (who will happily replace you just as soon as they think it makes sense to do so).

Do not let them gaslight you. Do not let them make you feel guilty. They will try. I’ve seen it first hand more times than I care to think about. Abusers will try every trick in the book to manipulate you in order to get what they want. You may need to work very hard to keep it from working on you.

When you give notice, they may even try to guilt trip you or attempt to convince you how “important” you are or even try to say that they aren’t accepting your notice. Screw that. You’ve arranged a way out and you’re taking it no matter what they try to do. They don’t get to keep you.

Make sure you use up your vacation and sick time before you leave. That’s a part of your salary and not all states require it to be paid out to you when you quit. Not taking that time doesn’t make you “dedicated” or a “team player,” it means you’re being taken advantage of.

Besides, you shouldn’t be “dedicated” to a place that is abusing you in the first place (though I know from personal experience how difficult it can be to really convince yourself of this).

Companies will still hire you if you leave a toxic job shortly after taking it. It’s not the black mark that so many articles and insecure bosses make it out to be. In fact, it’s generally only the bad ones that try to view “short resume entries” as a sign that an employee is bad instead of as a sign that the company they worked for was bad (or, at best, not a good fit).

You only get one life. Don’t let someone run you into the ground, ruin your health, and possibly end your life just so they might have the chance to profit from your suffering. There are better options out there.
October 14th, 2022

Happy birthday
Interviews Are Not Like a Normal Work Day

October 9th, 2022

A couple of days before I’m writing this, a post from a “senior” engineer came across my feed in twitter. In it, he was talking about an interview he gave less than 24 hours before, and about how the candidate couldn’t figure out how to close a tag in markup after he told the candidate that they weren’t allowed to use a library that they were going to leverage.

He used this as an argument for “this is why we need interviews. ‘Senior’ developers can’t even use markup properly” (paraphrase).

Thankfully, the people that I follow who were responding to this were taking this person to task for his behavior, though far too many people in the thread were jumping to his defense.

Let’s get the obvious (to me, at least) part of this out of the way – there is no way that I would want to work with/for a person that might drag me in public after I interview with them. That’s a huge red flag and I think the candidate dodged a bullet there.

Now that I’ve gotten the “Don’t be a shite person” thing covered, I’d like to talk about why coding interviews aren’t a good indicator of a candidate’s abilities.

The ability to interview well and to actually do the job are two distinct skillsets and have very little to do with each other. Daily work (in theory, at least) is a relatively psychologically safe situation in which you are able to leverage your knowledge, skills, and ability to learn in order to solve problems. An interview is a contrived stress test largely designed as a hazing ritual to make the interviewer feel smart and/or superior.

I say this as someone who interviews people regularly and tries to break this cycle.

My daily work involves spending time thinking about problems, looking things up, asking people questions and writing short, experimental pieces of code under test to fulfil the use cases that are going to provide value to a business.

In a live-coding interview, I’m going to have a problem dropped in my lap with no time to think about it, with a development environment that I haven’t customized (or worse, a whiteboard), while being watched and judged by people that I don’t know and don’t feel safe around so that I can “prove” that I am “worthy” to work with them.

Anybody see a difference here?

Work is filled with considered, largely unpressured choices. The interview is filled with snap decisions about a thing I have not had time to think about in a hostile environment (and don’t pretend that live coding interviews aren’t a hostile environment. You’re putting someone’s livelihood on the line. The list of things more hostile than that is fairly short).

That’s not getting to know someone and their abilities. That’s an unnecessary stress-test. And it’s especially going to work against people in marginalized communities – everything from BIPOC to people with PTSD to people with autism and countless others.

It’s not due diligence. It’s needless cruelty. (And I can speak as a Native person who has PTSD. Interviews as most people conduct them suck and make me want to crawl under a rock).

Want to know another secret? I’ve been writing code professionally for about 20 years now and it’s generally agreed upon that I do, in fact, know what I’m doing (most of the time). That said, I make plenty of stupid mistakes even when I’m not under pressure. We all do and we need to admit it.

I can’t tell you the number of times that I’ve forgotten to initialize a List<T> and then spent time trying to figure out why the code blows up when I do something with that list. Granted, TDD and improved IDE tooling have helped me spot those mistakes faster now, but they still happen.

John Peel may have been able to say “I never make stupid mistakes – only very, very clever ones” but I’ll tell you here and now that I am quite capable of making stupid mistakes. Sometimes I’ll cringe at them in the moment, but I’ve gotten better about laughing instead (which is something that an actual senior developer should be able to do, in my opinion).

If I, a senior+ developer (my current title is Architect), make mistakes like this in a no pressure environment, imagine what live coding in a high-pressure situation is like. Now ask yourself what that situation is like for someone with less experience or who has experienced more trauma than I have.

Don’t do that to people. Just don’t. There are better ways to figure out if someone is a good fit for your team.

And for the love of everything decent, even if you are still giving live-coding interviews (for whatever reason), don’t publicly drag the person the next day. I don’t care how bad you thought they did from a technical standpoint.

For the people out there who are being interviewed – if you see your interviewer speak badly about other candidates (or, even worse, if they do it in the interview – and I’ve been in a few of those as a candidate), consider if you want to be exposed to this on a daily basis.

Provided that you are able to cover your bills, you have options and you should be someplace where you can grow and thrive. If you can’t cover your bills and need the job, take it and keep looking. The saner people and companies will understand.
Don’t do Lunch And Learns

October 2nd, 2022

Professional development is honestly a requirement if you’re going to work in technology. The landscape changes constantly – sometimes it changes quickly, other times gradually, but it does change and we have to keep up.

Today’s hot technology that will net you a 50% increase in salary may be considered legacy tech in just a few years.

Companies and professionals use a number of ways to keep up – everything from going to conferences to reading, watching videos, and hacking on personal/side projects.

Companies, I am going to give you a bit of gentle guidance – if you expect your employees to keep up with trends in technology as a part of their job, then make it a part of their job. Set aside time during their working hours for them to do professional development.

Even if it’s only a couple of hours a week, if you’re expecting them to learn as part of their job, you need to make it part of their every day routine.

If you want to go all out and send your people to conferences and trainings on a regular basis, by all means, please do so. That is fantastic and I applaud you.

However, if you hear me saying this and your reaction is “We’ll do a lunch and learn because then our people will learn and it won’t impact the work we expect them to do,” I need you to stop right now.

Seriously. Don’t do it.

You get your people for roughly 8 hours a day. You don’t need them for a 9^th hour. If they take a lunch, that time is for them not for you.

You don’t own the people who work for you. This is something you will hear me say often (both online and in person), but I repeat myself so often because it needs to be said far too frequently.

Time that your employees aren’t working for you is their time – this includes their lunch. You don’t get to dictate what people do on time that they aren’t working for you.

This is especially true in the current market (though you shouldn’t try to monopolize your peoples’ time even when the market is in your advantage. We have long memories and we all talk to each other).

Companies and managers out there will respond to this by saying things like “lunch and learns are a perk” (extra work is not a perk), “technical people like this sort of thing” (some do, but again, lunch is their time, not yours), or “We can’t sacrifice billable hours for this” (If you can’t allow an hour or two of non-billable time for your employee every week, you’ve got bigger problems), or “Doing this allows employees to show how dedicated they are to us and to their craft” (I’m not going to sugar coat this one – You’re scum and don’t deserve your employees. Yes, I’ve actually heard this argument in the past).

This is where I admit that I used to be a proponent of lunch and learns. I’ve even given a number of them. That was in a time and situation where it was better than the alternative.

We’re growing as an industry and we should grow as an industry. That means realizing that, if you expect your people to train, you need to facilitate them doing that – with time and resources dedicated to it.

Now, that’s not to say that nobody should ever learn new things on their own time (personally I commit at least a couple of hours a week to reading or working on something that interests me). However, expect any learning that they do on their own time to be things that they want to learn instead of things you want them to learn.

Treating your people like people instead of property is a low bar, but it’s one that a lot of companies don’t clear. Part of the way that you can stand out in the crowd as an employer is to make sure that your people are paid for the training you require them to take.
Don’t Manage By Jira

September 25th, 2022

At this point, most people in software dev have had some experience in dealing with Jira or similar tools.

These tools get a lot of hate for being clunky, annoying, and insert-other-often-valid-issues-here. Jira specifically gets a lot of hate for how it forces a lot of bad behaviors. This sort of makes sense when you take into consideration that Jira apparently started its life as a bug tracking tool.

But that’s not what I want to talk about. I want to talk about a way in which Jira, and Jira-like tools, should emphatically not be used – but that seems to be one of the main ways that they are used.

Don’t use Jira as a management tool.

You can use it to get a view of the work that is currently in progress, but far too many places obsess over the content of “In Progress” tasks and the metrics that go with them. This is an unhealthy practice and it needs to stop.

That’s not to say that Jira is useless. It isn’t. If you use it as a tool to help a team coordinate with itself, it’s actually not half bad as long as you realize that it does have limitations.

It’s a pretty decent tool to use in a geographically distributed team in order to have a view on the work that we think needs to be done in the next week or two. It also helps you track blocking issues if you do it right. It even helps teams not get off into the weeds if you use it to break up cards into thin vertical slices.

Yes, you can do all of this with a set of index cards, but that really only works for teams that are co-located in the same physical space. Digital Kanban boards open up a lot of opportunities for remote collaboration if you treat them as collaboration tools and not management tools.

Instead of using it as a collaboration too, a lot of businesses try to use it as a management and reporting tool.

They inspect the board to “make sure everyone is working” – which is a problem for a lot of reasons. Putting aside the fact that this is a terrible Taylorism-style management practice, the tools just plain aren’t made for it. Jira, for example, only lets you assign one person to a card, so using it this way discourages pair and ensemble programming.

They will insist that every thing you work on be added to the board. This is a bad approach. The board is for the team to self-organize and should only contain work that helps move the project forward. Ancillary work doesn’t belong there. If you want to know what people are doing outside of directly project-related work, ask.

Insisting that “all work should be tracked” is just a symptom of the Taylorism obsession that everyone be “utilized” at 100%. This is unhealthy for the people who work for you and will lead to burnout and high rates of attrition (which, among other things, will lead to a loss of institutional knowledge).

This leads to one of the other major problems with using Jira as a management tool (coupled with Taylorism management approaches) – an obsession over velocity.

Just because you’re moving a lot of cards doesn’t mean that you’re doing meaningful or impactful work. Focusing on throughput as a metric for productivity is a bad idea for reasons that I’ve written about before.

The list of reasons that Jira (and its competitors) are horrible management tools could go on for several pages, but I can’t blame the tool. What I do blame is the misuse of the tool to satisfy management ego and the desire for simple (but wrong and destructive) metrics to “manage” people as though they were cogs in a machine.

Jira is a useful tool. Just not for the way that a lot of places use it.

Writing software is a creative endeavor. You’re solving problems that nobody has solved before. If you aren’t, you should strongly consider buying the product that already exists to solve those problems so you can focus your time, money, and effort on solving problems that are core/differentiating to your business.

If you think that you can’t trust the people you hired to get work done, that means either that you hired the wrong people or that you have trust issues that you need to work on – both of those are failings on your part as a manager, not the part of the people doing the work, and those won’t be solved by obsessing over metrics.

Training

Emotional Detachment

Luck

What should we do instead?

Profit Centers

Cost Centers