The Misanthropic Developer

Not All Solutions Involve Writing Code

July 17th, 2022

As a software developer, you spend a lot of time studying, thinking about, and writing code. It’s in the name, right? There’s nothing inherently wrong with that. There is, however, a problem when you actually start doing the job.

You aren’t paid to write code (despite what you and, likely, your boss think).

You’re paid to solve business problems.

You get the job by proving that you can code. You do the job by solving pain points for the business, helping open new markets, improving operational efficiency, etc. When you’re more junior, that almost always involves writing code. As you get farther along in your career, you start looking at things more strategically (or at least you should).

Some bosses are of the opinion that you are just there to write code and that they are paid to come up with all of the answers, so you need to sit down and be a brain attached to a keyboard. Those bosses are incredibly wrong about a lot of things (as well as potentially harmful to your career and even your health). If you run into one, get out as quickly as you reasonably can.

So, working on the premise that your job is to solve business problems, what does that entail?

It involves a lot of communication and collaboration (apologies to those of you who got into this line of work to avoid dealing with people). You have to understand the problem in order to help solve it. You also need to understand the reasoning behind why the problem needs to be solved, if there is a threshold for time/expense where a solution becomes impractical/untenable, and (ideally) how this solution fits into the wider ecosystem that the company operates in.

That sounds really complicated, but it can be translated into plain English as – what is the problem? What does it keep us from doing? What’s our budget (both money and time)? How does this work with the rest of the business?

You also want to make sure that the problem the business wants you to solve is actually the problem and not just a symptom of the problem. (Trying to solve symptoms instead of the real problem happens a lot more often than you’d believe)

As you work through this, you may find out that the solution to the problem in front of you doesn’t actually need to involve code (or at least not nearly to the scale that everyone thinks at first).

Sometimes you find out the problem is a one-time issue that can be more effectively done by a manual process (Heresy, I know, but even Google admits this. One of the exceptions is in highly regulated environments where literally everything has to be automated in order to have an audit trail). Would you spend days, or even weeks, automating something that can be done manually in 20 minutes and only has to be done once (or maybe once a year)?

Sometimes you find out that the problem can be easily solved by tools that you already have – a spreadsheet is a good example. You don’t necessarily have to make a slick new site with a whizbang frontend if all someone needs is a table of data to look at for reporting purposes (sometimes it makes sense to go all out, but again, weigh the cost vs benefit). If you can write a couple of lines of SQL and dump the result into a spreadsheet, why would you spend weeks writing a page used by one or two people?

Sometimes you find that the problem doesn’t actually need to be solved. It may be that it’s a vanity project for someone higher up (in which case, you may still end up having to do it – costing the business money and costing you sanity. Hopefully you get to work with some cool new tech to add to your resume.) It may be that they misunderstood the problem and this comes out during conversations around how to address it. It may even be that, given the time and budget constraints, that it doesn’t actually need to be done because it doesn’t provide a benefit that outweighs the cost.

None of these things are always going to be the case. In fact, most of the time, the business problems you solve are going to involve writing code (which is good, because writing code can be fun. At the very least, it looks good on your resume – but so does delivering business results). Just enter into this as a stakeholder instead of someone who simply acts as a unit of output (that doesn’t look good on your resume, and it’s not a happy place to be eight hours a day).

At the very least, going through this process can lead to better outcomes for both you and the business because you will all actually understand the goals you’re trying to achieve and the benefits they bring to the larger organization.
Culture is Both what You Do and what You Tolerate

July 10th, 2022

You’ll often hear that the culture in your organization isn’t what’s contained in your mission statement or some document on your website, but rather the things that you do.

I agree with this statement. It’s extremely true. If what you say and what you do aren’t in alignment, the truth rests on the side of what you actually do. However, this doesn’t go far enough to cover what really shapes the culture of your organization.

What you do is a decent high-level measure of your culture, but the real measure is what you tolerate.

Do you tolerate a “superstar” employee being an asshole because “they’re so productive”? Tolerating assholes is part of your culture.

Do you tolerate your HR people or management team calling your employees “resources”? Dehumanizing your employees is part of your culture.

Do you look the other way or make excuses for people who make inappropriate advances on other members of your staff (or outside contractors, etc for that matter)?

Do members of your leadership support openly racist, xenophobic, etc politicians? Guess what – your culture is one that supports those things (whether you think so or not. Whether you like it or not.).

All of these things impact your culture. Some of these are obvious (even though a lot of companies will defend the “resources” one until their last breath). With some of them (like the political leanings) you can say “what people do in their own time is their own business” until you’re blue in the face, but the fact is that people don’t leave that at the door. They just hide it, and it absolutely will impact your culture – especially if they’re in a position of authority.

I’m not saying that you need to police everything your people do outside of work. I am, however, saying that you need to look for the signs that it is impacting your company’s culture – and those signs can be really difficult to spot in the early stages.

One of your biggest indications is probably going to be people in underrepresented groups either leaving in a steady stream, not joining in the first place, or going very very quiet because they know it isn’t actually safe for them there.

We often talk amongst ourselves and, after a while, you start to be able to smell trouble on the air. Things that a lot of people wouldn’t notice or just shrug off act like klaxons for us.

If you actually care about diversity and inclusion, you not only need to listen to people when they tell you there’s a problem, you need to notice when they stop talking or start leaving.

I’ll give you an example.

In one place where I worked, I made the comment that there was a really great Jamaican food truck about 15 minutes from the office that we should go to for lunch one day (one of the many great things about living in a city with a large number of different cultures in it).

One of the members of tech leadership said that he didn’t go on that street. My joking response was “what? No sense of adventure?” to which he responded “I don’t go where adventure could find me.”

When he made the initial comment, I already knew where this was going (and something about him had made my teeth itch before that, but I didn’t have any proof). The street was in a lower-middle class predominantly Black neighborhood. It wasn’t a dangerous area, but that doesn’t stop racists from showing themselves.

I’d wager most of the people that were standing around completely missed the importance of what was said in that exchange.

I learned and honed several technical skills while I worked there, but the place never really felt right on a visceral level. There was a definite clique-oriented culture, only a few women, and not that many people who visibly weren’t white (I have pale skin, so I can sort of pass. Again, ask me why I have a beard sometime).

Several years later, I found that it didn’t end with tech leadership. I was, at the time, followed on twitter by the original founder of the company. And he started making pro-Trump posts.

Just some food for thought.
You Can’t Copy Your Way to Success

July 4th, 2022

“Do not seek to follow in the footsteps of the wise; seek what they sought. Seek the meaning behind their footsteps, and not upon the steps themselves. For in seeking the footsteps you shall be glancing only upon the next footprint. And you’re sure to stumble upon an unforeseen obstacle.” – Matsuo Bashō

There is a huge trend in business where companies will do something because a company others consider to be successful does that thing. It becomes part of “the formula” for success – or at least the companies copying the behavior think so.

The problem is that they’re wrong.

You will never make your way to real, lasting success by following the steps someone else took. You may have temporary success, but it won’t last long for a very simple reason – your situation is not the same as the person/company that you’re copying. You have different circumstances, challenges, assets, and customers.

At best, you’ll be copying the answer to a similar problem, but by the time you’ve succeeded in copying it, the nature of the problem has changed and the person you’re emulating will have changed strategies to deal with the changing situation. At worst, you’ll be applying tactics and strategy that have no relation at all to the problems you’re facing.

You see it with every company from the smallest startup to larger orgs trying to copy Google (you don’t operate at that scale, sorry), with everyone and their brother trying to mimic Elon (please don’t. We don’t need more narcissistic jackasses), and other examples that you can spot around you.

The hilarious thing is that they don’t just try to copy business practices (which might be at least somewhat understandable), but instead they try to copy everything. For example – how many companies try to interview like the FAANG companies today with leetcode and grilling candidates on things that have nothing at all to do with their job? (Before that, it was the Cult of the Puzzle, which was just as ridiculous and dehumanizing)

This isn’t a new trend, nor is it restricted to tech and tech-adjacent companies. Manufacturers have tried to copy Toyota for decades and never understood why they didn’t get the same results.

If you want to know the reason, it’s because for any given thing that they copied from Toyota, within a short time, Toyota had moved on.

Toyota doesn’t invent processes as an end-result tool. They create processes gradually, and change them regularly in order to progress toward a goal. Their aim is kaizen (continuous improvement) toward a long range target (reduce waste by x%, move closer to a 1 to 1 workflow, etc). That means that, for any given process, it’s only a step along the way and copying it isn’t going to give you any advantage.

In short, they’re playing a completely different game than their competitors are. The same is true of the actually successful tech companies that others try to emulate (we’re not going to get into the ones that only look successful at first glance. That’s a whole other post if I ever decide to write it).

If you want to read more about this, the book Toyota Kata by Mike Rother is well worth getting. Abstract the lessons you learn there and apply them to your approach to problem solving and strategic improvement.

The ironic, and hilarious, correlation to this is that the practices that are most quickly abandoned by the groups others copy are the ones that take the longest for the people copying to stop doing – partially because they think it’s some kind of magical incantation and partially because those wrong things are easy to do.

A prime example of this is the obsessions with puzzles in interviews (which some places still do. If you want an overview of this, go read How Would You Move Mount Fuji). The places that developed this methodology eventually realized that not only did they not have a positive correlation with high performing employees, but they actively discouraged high performers from applying because they didn’t want to deal with it.

The places copying them, however, kept doing it for years (sometimes decades) afterward.

It’s easy to copy someone else. It doesn’t really get you anywhere, though. If you insist on emulating another company, look at the things that they do as they relate to the current situation that the company finds itself in. See why that company is doing the things that they’re doing instead of fixating on what they’re doing.

That’s a much more useful exercise. Figure out the pattern and whether or not the pattern (or something like it) is applicable to your situation. You’ll need to adapt it heavily, and more often than not the reasoning behind the pattern is going to be more useful than the pattern itself – in particular, using the pattern as a way to identify the pain point that the company is trying to alleviate.

Is this pain point something that your own company has? Is it actually a pain point in your case (it legitimately may not be, or at least not yet)? If so, what steps might make sense in order to work on lessening that pain (or is it worth focusing your effort on another, more important, pain point)?

Stop trying to copy others in order to be successful. Instead, look at the reasoning behind the things that they’re doing and see if and when it applies to you.
Trust During The Interview Process

June 26th, 2022

I’ve been on both sides of the interview table a number of times and I can tell you that there’s a huge divide between the best experiences I’ve had and the worst ones. If we’re being honest, there’s a pretty big divide between the mediocre ones and the worst ones too.

One of the largest variables that you can change which will have an almost immediate impact is Trust.

Trust the candidate. Seriously. You want the candidate to trust you, but to get that Trust, you are going to have to extend Trust first. Otherwise, you’re going to be operating from a position of mutual distrust and, as a general rule, that doesn’t work out very well.

I know there are people reading this who are going to say “We can’t trust them. People lie all the time and we can’t take that kind of risk”

Yes, people lie sometimes. My advice still stands – you will gain more from extending Trust to your candidates than you will lose doing so. You’ll most certainly gain more by trusting them than you’d lose by not trusting them.

I’ve hired quite a few people. In all of that time, I’ve had a single not-so-great hire that I can think of off of the top of my head. Not to be immodest, but that’s not a bad track record.

I have, however, seen a number of things from hiring managers and recruiters that I wouldn’t consider a red flag so much as a marching band complete with flag corps and maybe a few horses decked out in feathers and sequins.

A couple of notable examples:

Demanding to see a potential candidate’s ID to prove they are who they say when you call them to discuss positions with companies that you are sourcing for. You also don’t need to have them fill out paperwork complete with reference list just to discuss opportunities that you may have.

Crawling into every nook and cranny of experience a candidate has had over a decade (or longer) career. A simple conversation about what they’ve done and the challenges they’ve dealt with can generally tell you whether or not a candidate passes the sniff test – especially early in the process. If you can’t tell this from a conversation, you probably shouldn’t be the one having it…

During the course of the conversation, you can dig into the things they go over in order to gauge their skill level, but that doesn’t really take an interrogation either. You’re talking to someone you want to be your peer. Act like it.

The sad thing is that the two examples above aren’t exaggerations at all. In fact, I’ve had people try to do the second one more times than I care to think about. If we expand it out to my circle of friends, both of these things have happened a depressing number of times.

Thankfully, since my friends and I have the ability to do so, those recruiters and managers are quickly (and usually politely) informed that we are not going to tolerate that sort of behavior, the interview/conversation is ended, and they go on our List of people to not work with again. This has the added benefit of dissuading them from doing it to others.

Remember that an interview process is a two-way street. The candidate should be deciding whether they want to work with you just as much as you are deciding on them. If you display a lack of Trust during your conversations, what are they going to reasonably expect if they said “yes” to working with you?
Questions From a Developer Bootcamp

June 19th, 2022

I was recently invited to take part in a panel discussion at a coding bootcamp about lessons I’ve learned as a developer. I’m always surprised when I get asked to do this sort of thing because I know people with a much larger audience than I have and I’m used to them being the ones who get reached out to.

I do, however, enjoy doing this sort of thing. Partially because it’s nice to be able to possibly help other people, but also because I didn’t really have any role models or mentors in tech until I was in college or close to it, so being able to be that for someone else (even for just an hour or two) is something that I’ll almost always say yes to if I have the time (and I’ll generally try to make the time).

The organizer did a really great thing ahead of time and sent us a list of possible questions that we’d have. The panel was only about an hour, so we didn’t get to all of them, but I thought they were good questions so I’d like to answer them here.

I’d like to thank the folks who teach at and run Cincinnati’s Tech Elevator campus for inviting me, but most importantly, I’d like to thank the students there for not only listening to all of us waffle on, but also for asking such great questions at the end of the panel (and for connecting with us afterward).

How important are soft skills in a technology role? Which soft skills are the most important?

Soft skills is the wrong term, honestly. They’re core skills, and they’re frequently harder to acquire and grow than learning a programming language is.

You’re building things for people that solve problems. Communication, asking the right questions, and helping each other figure out a good solution to the problems is most of what we do.

Honestly, writing code is often the easier part of the exercise.

Don’t feel bad. It took me longer than I care to admit to come to that realization. In school, they teach you how to code. They don’t teach you what to code or why to do it (or, just as importantly, why not to do it).

What are the various job titles involved in a technology team? What other dev-related roles within a company should students be considering? How do those roles work together on projects or work?

Tech as a field is huge. Apart from developers, you have business analysts, testers, architects, infosec people in more varieties than you’d believe, scrum masters, product owners, project managers, and a whole host of others. Not all of them require writing code. All of them involve understanding people.

What is it like working for a startup versus corporate company versus mid-sized organization?

This is a really good question to which there isn’t a hard and fast answer. We’ll go with a few generalities instead. I’ll stick to what the jobs themselves are like because I could write a small book on the comparisons of culture, workload, etc.

Startups tend to be quite ad hoc with regard to who does what. You’ll find yourself doing a bit of everything. You end up wearing a metric ton of hats and learn a lot. Titles and responsibilities are often at least a bit fluid if not outright made up (especially in the early days of a startup).

Most of your time is going to be spent trying to find market fit with a product, or figuring out what product you should actually be making in the first place. Depending on the funding model (VC vs bootstrapped, etc), they may not be making a profit at this point.

Mid-sized orgs tend to have at least a bit more structure than startups. For example, your devs aren’t likely to do a lot of copy writing or marketing unless they’re giving presentations at conferences, sales meetings, etc.

They’ve probably already got at least one product or service that brings in money, and their cashflow is going to be net positive.

Large corporations really depend on what part of the corporation you work in – often all the way to the manager that you work for. They can honestly run the gamut from being like the Kafkaesque Big Cos that you see in the movies all the way to some teams operating in an extremely responsive and agile way.

What is the biggest misconception about being a developer?

That we’re antisocial people who sit hunched over a keyboard all day. The best developers that I know are warm, socially aware people who care not only about shipping well written code but about solving problems that matter to real people.

What is one thing you would have done differently in your career?

I’ll give you two things because I think they’re both important.

First, I would have focused on the people-oriented aspects of things much much sooner. More grace, less force as my old teacher would have likely put it.

Second, I’d have worked to realize that I don’t have to be perfect a lot sooner than I did.

Both of these things are harder for me than I would like because I grew up in an abusive environment where, among other things, anything less than perfect wasn’t “good enough.” It took me a long time to get to the point where I can at least shut up the voices of my parents that live in the back of my brain long enough to get things going – after that point, keeping momentum isn’t as difficult for me (thankfully).

How can students get involved in the local tech community? Examples: Meetups, networking, events, etc.

If you’re comfortable with going to things in person (since we’re still in the middle of a pandemic), go to user groups and meetups that interest you and go to conferences if you can afford to. Talk to people there. If you feel comfortable enough, offer to speak on something that you’ve learned.

If you’re looking to get involved online, there are a ton of discord chats out there in addition to twitter and LinkedIn. Connect with people, interact with them.

At the end of the day, you’re all people. Relax, take a breath, and be yourself.

Networking is literally just talking to people and getting to know them. Don’t go in with the expectation that they’re going to give you things. Sometimes you can help them. Sometimes they can help you. Sometimes you just talk. Sometimes you meet someone you don’t mesh with. This is all okay. These things take time. Don’t force it.

What is the hardest thing about being a developer?

The fact that, as you get more senior, the roles that you are expected to fill often involve less developing code and more mentoring people. They’re two very different skillsets and, sadly, most places don’t teach you how to do the mentoring part.

Some people resent that this is the case. Some welcome it. Either way, the truth is that as you go along, the biggest impact you will be able to make is to act as a force multiplier for others.

What type of person does it take to be a developer?

Do you write code? Go and look in the mirror. You are the type of person it takes to be a developer.

I’m being completely serious. You’re the type of person that you need to be, and don’t let people try to tell you that you aren’t good enough because that’s their own insecurities and not a shortcoming on your part.

What is the difference between an average developer and a really great developer?

We all have strengths and weaknesses. Most of the people you consider to be “great” developers are excelling at a particular class of problems that they have put a lot of time and effort into. Put them into other problem domains and they aren’t nearly as impressive.

On a team, you have a group of people that work together and have a complimentary set of skills, experience, etc. None of them are “great” by themselves.

Don’t get into the mindset that you have to be “great” (and I realize how difficult that is. Believe me).

In the end, the only person you’re competing with is yourself and your objective is just to improve over time. Whether you move forward a mile, a foot, or even just an inch, if you keep going you’ll make more progress than you ever believed is possible.

What advice would you give to someone just entering the field?

I’ll give you two pieces of advice. Both are important.

First, ask questions. You’re not going to know everything (no matter how long you are in the field). Asking questions doesn’t make you weak or a bad developer. People who tell you that it does are jerks and you’re better off not listening to them.

Speaking as someone who interviews people, being on the other side of the table sucks too, just for different reasons. We want the people we hire to succeed. We don’t hire you to watch you fail. If there are things that we can do to help you succeed, we’re probably going to do them, so if you have questions, please ask. You’ll not only be helping yourself; you’ll also be helping us.

Second, remember to take time for your life and the things that are important to you. At the end of the day, you can get another job. What you can’t get back is the time that you’ve spent or your health (and some companies will try to wring you out until there is nothing left if they think they can get away with it).

Don’t listen to the people who tell you that you have to work 80 hours a week in order to get ahead.

What do you look for in a team/organization that you are considering joining?

Work that I do not find morally objectionable, work-life balance, people that I think I can learn from, problems that I find interesting, no jerks, and decent compensation.

I’ve probably forgotten a number of things at the moment, but those are some of my key criteria.

What are your favorite tools/technologies/platforms to work with and why?

Honestly, at this point I view tools, technologies and platforms as a means to an end. I can learn pretty much any technology that you put in front of me, though I will admit that some are more painful than others.

I joke that I’ve brought down production in almost a dozen languages, but it’s kind of true. I’ve written everything from line of business apps for small and medium businesses to embedded software for really large farm equipment to security hardened web apps for the DoD to automation software for a Fortune 50 mega bank.

At the end of the day, tools are just tools. Expect Perl. No more Perl please.

What are your favorite projects to work on?

Things that have a positive impact on the world around me. They don’t have to be huge, amazing things, but knowing that I’ve been able to improve the lives of others is kind of a big deal for me.

What are your least favorite projects to work on?

I have three classes of project that could fall into this category:

Things that I’ve done countless times before – with the exception of where it helps make the world a better place.

Projects that don’t improve the lives of others but exist solely to make a profit (making a profit is fine, but some things exist for that purpose alone).

The last class of projects I actively refuse to work on if I have a choice – something that causes excessive harm in the world around me. I’ve turned down director+ level positions at companies that would have caused me not to be able to look at myself in the mirror.

I realize that all three of these are an exercise of privilege, but thankfully I usually have the ability to avoid them.

How can students best prepare for a technical interview?

I’m not sure that I’m the right person to answer this for dealing with the majority of technical interviews because the things I do on the other side of the table tend to be different than many/most people.

If you’re interviewing with me, it’s more likely to be a conversation. Things you’ve done, challenges you’ve faced, things you enjoy, what you want to do next, etc. I’ll dig into what you say to gauge where I think you are skills wise, but I don’t go in for the grilling style interviews.

I look for culture add instead of culture fit.

I’ve interviewed people at levels from fresh out of bootcamp all the way to very senior this way and it seems to work well for me.

What was the most important lesson that you have learned in your career?

That there is always another job. It’s not worth it to drive yourself into the ground over a job that, by definition, won’t love you back. Your time and health are things that you don’t get a second chance to have.

There can always be another place to work.
Culture Fit vs Culture Add

June 12th, 2022
If you spend any time giving interviews (or much time going through the interview process, honestly), you’ll probably start to hear people talking about “culture fit.” The amount of people that obsess over the concept boggles the mind.

And it’s the wrong thing to do. In fact, it can be actively harmful to not only the person interviewing for the position, but even the company they’re interviewing at.

“Culture fit” as it’s practiced in a lot of places leads to one of two things:
- An unintentional monoculture where everyone looks, thinks and acts the same
- A thinly veiled reason to discriminate against people (which, in turn, leads to a monoculture where everyone looks, thinks and acts the same, only it’s done on purpose)
If you think I’m blowing the discrimination part of things out of proportion, ask a Black person how many times they’ve heard that they “weren’t a good fit” for a role that they were extremely qualified for. Or, if you’re in the mood to hear me rant, ask me why I grew a beard and how I literally started getting offers consistently within a few weeks.

Yes, the people on your team need to work well together. That’s a given. That doesn’t mean that they need to “fit” into your current culture. In fact, maybe your current culture is toxic or otherwise sucks and it’s holding you back.

Don’t hire for Culture Fit. Hire for Culture Add.

Looking for what someone can add to the culture of the team actively works against forming a monoculture because you are explicitly looking for someone who doesn’t think like everyone else on the team and probably has a vastly different background.

I’ve interviewed a lot of people over the course of my career. My basic checklist is as follows:
- Do I think they can do the job (or grow into it in a reasonable amount of time)?
- Are they an asshole? (the answer to this should probably be no)
- Do I think they can get along with the team, clients, etc fairly well?
- What would them working with us add to the team that we don’t already have or don’t have enough of?
- What problems would adding them cause? (This is mostly so I can make myself aware of potential issues within my existing team and is a way to be aware of possible pre-existing biases)
Seriously. That’s probably 95% of what I’m gauging when I give an interview. All of the questions I ask; all of the time I spend actively listening to what’s going on in the interview; all of it – it’s all to answer at least one of the above questions.

I don’t want a team full of people that look, talk, act, and think like me. Are you kidding? That sounds like hell on earth – not to mention practically impossible given the demographics that I fall into.

A team full of clones of me would drive me nuts and would cause me to stagnate because I wouldn’t be introduced to new things in an organic manner nearly as often. It’s not that I’m a bad person. It’s that I know that I have the habit of following things down rabbit holes unless I catch myself doing it. I like being around people who are different from me because it gives me the chance to look at things from different angles.

Could I use an extra “me” around once in a while? Sure. But a team or company full of copies of me would be like the scene in Pirates of the Caribbean where Jack Sparrow is in Davey Jones‘ Locker and the entire crew of the ship is copies of him.

I have strengths, but I also have weaknesses and I realize it. So do you. Having a diverse team helps the team be stronger because where one person is weak, another member of the team may be strong.

Monocultures don’t get that benefit (or at least not to nearly the same extent) and both the members of the team and the company suffer for it.

Don’t believe me? Look at the motion activated faucets that don’t work well for people with darker skin, products that aren’t accessible to people with disabilities, facial recognition software for photographs that crop the image to lighter colored faces, etc. All of these things (and more) could be mitigated by having a more diverse group of people working on the products in question.

Diversity isn’t a checklist activity. It’s something that makes us all stronger. Throw culture fit out the window and go for culture add. You’ll be better off.
Put Your Risks and Failures Into Perspective

June 5th, 2022

Most of us have an inherent fear of failing. I include myself in this. Failing sucks. It’s no fun, it’s embarrassing, and far too many of us grew up hearing “If you don’t do $x, you’ll be a failure” (or various other permutations on the concept).

The truth is that, on the whole, failure isn’t a big deal. It’s actually one of the best ways that you learn. Sure, there are times that failure has lasting consequences, but most of the time it’s temporary.

You failed at something. Did anyone die? Come out of the deal with lasting injuries or disabilities? Face financial ruin as a consequence? If you answered “no” to these, then you’re fine.

I should note that I’m not making fun of the above situations nor am I exaggerating. I’ve been in several of them, so I can speak from experience. Thankfully everyone (so far at least) has survived. It’s part of the reason that my most common response to something going wrong is “If that’s the worst thing that happens today, I think we’ll be alright.”

Even after that, I still openly admit that I have issues embracing failure sometimes. There are ways that I’ve found helpful to not only deal with failure but with the fear of failure that too often keeps us from doing what we want or need to do. I’ll go over one of them here.

Let’s put our (potential) failure into perspective.

What happens 3 minutes after we fail?

We failed and feel like we’ve lost face. Someone may even be chastising us for whatever went wrong. It sucks. If it was at work and we still have a job, we have a couple of choices – fix what went wrong (if necessary) or go for a walk to clear our heads.

What happens 3 hours after we fail?

Those of us who deal with anxiety are probably still stewing over our failure a little bit, but that’s okay. It will pass. For most problems, we’ve already fixed the issue or moved on with our day. For some of the more severe stuff, we may still be dealing with consequences (needing to get our car repaired for instance) but for the most part, things are probably at least mostly back to normal.

What happens 3 days after we fail?

For most issues, pretty much everyone will have moved on. A lot of times, it might become a good-natured joke that we failed at something we thought was a big deal at the time, but in the end didn’t really matter.

What happens 3 weeks after we fail?

We’ve learned a lesson or two and the failure probably doesn’t matter past being a valuable learning experience. We may even have found a better way to do whatever it was that we failed at.

What happens 3 months after we fail?

With the exception of severe incidents, almost nobody is going to remember.

Are there instances where the above doesn’t hold true? Sure. This is especially the case in instances of severe injuries or the rare mistake that literally causes a business to fold (though the latter is almost always a series of mistakes and not some single issue).

For 90% of what we deal with on a regular basis, though, by the time the weekend comes around, nobody is going to care that you made a mistake. If you have a boss that harps on every failure you make, I’d suggest looking for a healthier place to be – I’ve worked in those environments and they can literally destroy your health.

So if you’ve failed, or you’re afraid that you will, take a step back and think of what the worst likely result is going to be at the above points in time. If the negative consequences don’t last more than a day or so, try not to worry too much and do what you feel like you need to do.

I realize that sometimes it’s easier said than done, but as the saying goes “you miss 100% of the shots you don’t take.” Mistakes are a part of life. Most of the people you view as successful have made more of them than you’d believe. Remember that you’re only seeing their highlight reel and don’t try to compare it to your day-to-day experiences.
Stop Trying to Replicate “The Office” at Home

May 30th, 2022

We’re year three into a pandemic and it’s caused a lot of changes in not only the way that we live, but also in the way that we work because, the call to “return to office” notwithstanding, most people in tech have been working remotely.

There are some great benefits to this – a commute measured in the time it takes to get your coffee instead of in hours, less expensive (and healthier) lunch options, more time to spend with family, etc. This is the sort of thing that I am totally for because you should work in order to live. You shouldn’t live in order to work.

One of the dark sides to the situation, however, is the expectation that a lot of managers and businesses currently have that working from home should be just like working from The Office.

I’ve heard countless people in various positions talk about how the background in your video calls should look (mostly sterile), complain when people have video off, or try to say things like “you can’t do work in sweatpants” (when they have no idea what kind of pants you’re wearing).

Let’s get this out of the way right not – working from home and working at The Office owned by a company are two completely different things and that’s a good thing.

Working from home lets you get things done in a space you control. If you’re fortunate, you have a room more or less dedicated to working (it really helps to get out of the “I have to work” mindset when you can just leave the room at the end of the day). For a lot of people, though, their desk is part of a living room, bedroom, or dining room – and that’s fine!

Working from home lets you set things up so that they’re comfortable for you – whether that means that you work in a space that’s totally neat, tidy and free of anything on the desk, or you work surrounded by surreal sculptures and have three cats sitting next to you. It’s your space.

And that’s something that managers and businesses need to come to terms with – they employ and work with people.

Part of what comes with that is that many of us are members of minority groups that face discrimination for basically just existing. Our homes, and therefore our home workspaces, are probably going to contain things that might open us up to discrimination or microaggressions.

Take that into account when you demand they always be on video meetings (trust me, we keep track of the people who aren’t safe to be ourselves around and some of us are in a lot of different kinds of closets for the sake of surviving at work), or that they not be allowed to use virtual backgrounds, etc.

We’re not going to get into how asinine it is to tell people how their home spaces should look.

The Office is a space owned by someone else. They set the rules – and those rules are often made in some bizarre view of what “professionalism” is (which, to them is usually translated as “show no personality because you’re a cog in a machine and I’m the one ‘in charge’”). It’s a place where people come to work sick (which makes other people sick), you often have to wait to go to the bathroom, you can’t have “too much” on your desk (if you even have a set desk), and where most people really don’t feel comfortable.

That’s not professionalism. That’s ridiculous. Why would you want to replicate that in your home?

My home office is a place where I can get work done and be comfortable doing it. It looks, generally speaking, the way that I want it to (there’s always room for improvement). It doesn’t look sterile and 90% of it will never be on a video call because it would raise questions about things I really don’t want to go over with coworkers.

The video calls only get to see the shelving behind me filled with fabric bins from Ikea, a mask on the wall, and a few odds and ends on the top shelf. They don’t get to see the other shelving full of camera equipment and tools, the racks of swords (I grew up training in martial arts), the wall hangings, or any of the myriad of other things in the room that represent some part of the path I’ve walked.

I’m fortunate to have an actual home office, but it’s not sterile in the least. It’s a place where I do more than just work on code and have video meetings with clients and coworkers. It’s seen more than a little soldering, leather work, video and audio editing, and a variety of other things.

Everything in here is either for some type of work, is there to make me more comfortable, or tells a small part of the story of the person who I am.

There’s nothing unprofessional about that at all. In fact, being able to do the work and having a personality while you do it is something that more “professionals” should strive for and what more bosses and companies should not only accept but also embrace.
Move Fast And Break Things is Great – Until It Isn’t

May 22nd, 2022

So much of the tech sphere, and a lot of businesses in general, have fallen in love with the mantra “Move fast and break things” that was a motto at Facebook in its early years.

On its surface, it’s a great idea – take chances, do stuff, see what works, and don’t be afraid to stop doing the things that don’t. Even past the surface level, it’s a decent strategy. The problem is that, like so many other great ideas, people parrot it without realizing why they’re doing it.

There comes a point in the development of your product that “Move fast and break things” not only stops being a benefit, but actually becomes a problem – and that point is when you have found a market fit and have actual (usually paying) users relying on your product to get things done.

It’s the reason that, even though we have API versioning, the general advice is that changes to an API should be additive instead of breaking existing functionality. Once people rely on your product, if you break the way it works for them, there’s a very real chance that they’ll stop using your product and go somewhere else.

Moving fast and breaking things is great for when you’re trying out ideas, trying to find a market fit, or doing prototypes. It stops being a great idea when it threatens your viability as a product or business. You need to figure out what your risk appetite is and what the potential rewards are of breaking things.

That’s the part that a lot of the people who just repeat mottos don’t understand. That particular motto is there to get people to take risks when playing it safe is the real risk. It’s not that you should completely reboot your product every six months.

Of course, there’s a dark side to stability and backwards compatibility too – just look at some of the baggage Java or Windows have to allow for backwards compatibility. (There’s actually a hilarious reason that Windows went from Windows 8 to Windows 10 – supposedly a lot of legacy software made after windows 95-98 era did a check to make sure the version didn’t contain the string “Windows 9” because it wouldn’t work on older operating systems).

Stop following mottos without questioning why they’re being used. Your path isn’t the same as the person who created the motto, but there is every chance that you can learn something from them. Just understand why you’re doing it.
Your Resume is a Marketing Document – Nothing More, Nothing Less

May 15th, 2022

If you look on social media (or, worse, the people who are trying to sell books on resume writing or resume writing services), you’ll see a lot of conflicting statements about what your resume should be like, how long it should be, words to avoid, and various other topics.

Let’s make it simple. I’ll give you the advice that I’ve given a lot of people in the past – the vast majority of those posts can be ignored if you keep one thing in mind – your resume is a marketing document. No more, no less, and what you’re marketing is yourself.

Your resume has one real purpose – to get you an interview with someone who has the ability to hire you. After that, its main use is to give you things to talk about in the interview. The person looking at your resume should say “Wow. That sounds great! Tell me more about that!”

That’s it. Seriously.

With that in mind, I do have some advice for how to approach writing it because I prefer to give people actionable things instead of just waving my hands and walking away.

Use Business Results

Put things that you’ve done in terms of impact to the business. It’s really great that you used AwesomeTech at Company Y, but what did you accomplish with it?

Did you release a product that lead to income or savings to the business? That should be in your resume. If you have an approximate amount that you made/saved (either dollar amount or percentage), even better.

Did you improve performance of existing processes? Did you do something that improved the security posture of the organization? Maybe you did something that allowed them to release software faster, leading to being able to provide business value in a shorter time span? All of these sorts of things should be in your resume. If you can put numbers on them, even better.

Hiring managers will look at the things you’ve done for other people and will see themselves being on the receiving end of these results, so put things in a way that lets them easily do just that.

Show Leadership Where Possible

If you mentored other team members, were involved in hiring new people for you team, or any number of other things that can fall under the umbrella of leadership, put those things on your resume.

It shows that you did more than just sit there with your head down, cranking out features.

In fact, even if you didn’t lead people, but you guided the design and architecture of the systems, that’s a form of leadership too (and a valuable business skill). Put that on your resume.

Only Put What You Want To Do

Have a technology that you hated working with and never want to touch again? Leave it out of your list of skills. The list of things that you can do doesn’t have to be exhaustive. You’re allowed to leave things out that you don’t want to do anymore.

Have a skill that you haven’t used in a paid job, but are able to do and want to do? Go ahead and put it on your skills list. If you have code you can point to and say “I did that,” you’ll be fine. Any hiring manager that gives you grief for it is showing red flags.

Now, that said, don’t lie on your resume. First off, you’re almost certainly awesome enough to not need to. Second, you’ll probably get caught in the interview when they start asking you about it, so it’s counterproductive anyway. Third, honestly, I’ve always found that it’s just plain easier to remember the truth.

Full Time vs Contract Positions

You hear a lot of online “experts” beat the drum that you better make a distinction between full time and contract positions. I disagree.

Speaking as someone who has done interviewing and hiring, I don’t really care what the employment agreement was as long as you actually did the work. Most hiring managers that I know are of the same basic opinion.

The only time I might advocate you to bother putting that a job was a contract is if it was a fairly short engagement (say under a year) or you had a few of them in row in order to pay the bills so it doesn’t look like you were just jumping ship every 6 months.

The reason I suggest that is because some managers will complain if you have “too many” short entries (for whatever their definition of that word is). Stating explicitly that those were contracts can make skittish managers more comfortable.

To take it a step further, I honestly don’t care what placement company you did the work through either. If you were working on-site (or remote as the case may be) with a single client the entire time, just put that you worked for the client during that time period because you did.

It doesn’t really matter who cuts the checks unless you have to fill out background check paperwork at some point. If they start questioning you about it, tell the truth – that you were doing work for Company X as a contractor with Company Y. Most people really aren’t going to care.

If you’re working for an actual consulting company (as opposed to a placement/staff aug firm that just plops you in a seat somewhere else), then you should say that you were working for the consulting company.

Resume Length

If I hear one more person claim that “resumes should only be one page. With a max of two pages,” I am going to scream. Your resume should be as long as it needs to be to convey to a company why they want to hire you.

I used to adhere to the 1-2 page “rule” and got far less interest from companies than I did after I expanded my resume. I believe it’s currently about 4 pages all told.

Make sure the first page outlines what you can/have done from a skills perspective. Don’t make people go hunting for it. You often don’t get much time from a hiring manager, so make it count. Page one should jump out at them – your skills, your major business impact items, your leadership, etc.

If you want a more concrete example of what I’m talking about, you can look at my resume here.

Toss the stodgy “resume rules” out of the window. The world has changed significantly since what they’ve been telling you was anything close to being true. Go out there, be confident, be amazing, market yourself, and get the next job that you really want.

How important are soft skills in a technology role? Which soft skills are the most important?

What are the various job titles involved in a technology team? What other dev-related roles within a company should students be considering? How do those roles work together on projects or work?

What is it like working for a startup versus corporate company versus mid-sized organization?

What is the biggest misconception about being a developer?

What is one thing you would have done differently in your career?

How can students get involved in the local tech community? Examples: Meetups, networking, events, etc.

What is the hardest thing about being a developer?

What type of person does it take to be a developer?

What is the difference between an average developer and a really great developer?

What advice would you give to someone just entering the field?

What do you look for in a team/organization that you are considering joining?

What are your favorite tools/technologies/platforms to work with and why?

What are your favorite projects to work on?

What are your least favorite projects to work on?

How can students best prepare for a technical interview?

What was the most important lesson that you have learned in your career?