Tag Archive | career

On Hiring: Developers Are Like Stocks

This post is for those of you who hire developers, and also junior developers who want to be hired. Let’s talk about how developers are just like individual stocks in the stock market. Time for a little role-playing: you’re now a stock market investor.

As a financial advisor, your company has given you $2,000,000 USD to invest in the stock market. It’s made very clear that the future of the company depends on the return on investment (herein called ROI) – “gains” – that your investments bring to the company. Your decisions will have a major impact on the company’s future. Given that kind of pressure, what’s your investment strategy for success? Begin by reviewing the kinds of stocks available to invest in.

Let’s Review Some Stocks

You take a look at stock #1. It has been on the market for a decade, has nearly consistently yielded high returns (with references you can investigate and check into), and is very reputable. Putting a good chunk of your money here is probably a reasonable call, since this stock is vetted and has historically provided value over time. It’s unlikely to suddenly drop to no value, and if you see it going south you can bail out before you lose it all.

Stock #2 is the interesting one. It’s brand new to the market. You can find no history on it, no performance trends, no reputation, nothing. It’s a total wildcard that has a reasonably low price tag – about 1/3 of stock #1. Its value could skyrocket resulting in incredible ROI. However, it could also end up being a dud, resulting in losing it all. You have little information to go on: this stock is truly a gamble. Do you invest heavily in it?

Given the two options above, what’s the smart move? In general, putting all of your money into a single thing is very risky, so you’re likely to diversify your portfolio a bit. It doesn’t make a ton of sense to invest heavily into stock #2 because it’s a major gamble, but there’s some room for potential and it might pay off. So why not put 80% into different stocks that fit the archetype of stock #1 and the other 20% in stocks that fit #2’s profile? That would make for a smart investment with some near-guaranteed returns, including some investment into gambles with high potential.

Stocks On Market == Devs On Market

Stock #1 is a senior developer with a proven track record and solid reputation. Stock #2 is a junior developer.

Hiring nothing but juniors is a recipe for high volatility and potential disaster, for reasons that become obvious when given the stock market analogy above. Hiring nothing but seniors is one way to get reasonable gains, however you miss out on significant potential to hire an incredible up-and-coming junior if you never hire any at all. A good strategy incorporates both, with seniors afforded time to mentor the juniors and develop their skills.

Getting Hired As A Junior

As a junior developer, the less artifacts that you can point to and show to companies, the more of a risk you are for them to take. You can mitigate some of this risk with a good interview, but if that interview doesn’t include coding tests which you ace then it might not be enough to get you in the door.

A junior should strive to create artifacts that reduce the risk of hiring them. These could take virtually any format, and given that everybody is different and we are not all afforded the same privileges and opportunities, one should strive to create artifacts that suit their situation. Single parent with 2 children and little free time? Put a few hours each week into an open source project (or contribute to other open source projects). You’ll be amazed how quickly that adds up. Unemployed with tons of free time? Create a project that shows off your skills and stretches your knowledge, which in turn causes you to learn. Struggling with the whole “I need a job to get the experience to get a job” thing? I’ve been there myself, and while my situation was surely not identical to yours, I found that investing some time into reading books and writing small applications to demonstrate my skills did wonders for potential employers.

The point is that all developers are going to sell themselves as hard as they can to a potential employer. To an employer, they may all look similar. Do what you can to stand out and reduce uncertainty by creating evidence of your potential and abilities, and show that to them instead. Talk is cheap, action speaks louder than words.

Dev Team Interactions: Accountability & Blame

As a developer working for a company, you probably work on a team. The interactions on these teams are sometimes pleasant, and other times hostile. What’s interesting to me is that a lot of the time, a hostile interaction could have been a pleasant one if only approached differently. Hostile teams are created by the actions of the people on them, not by the situations they encounter. One such hostile action is blame.

Blame

Blame is assigned externally – it comes from other people. You cannot control blame when it is directed at you. Blame tends to surface under tense circumstances, such as when the build has broken or a project has failed. It often rears its ugly head in the form of pithy and simplistic statements. “Jane broke the build again!” or “this is Mohinder’s fault!”

Blame is often facilitated – if not encouraged – by a poor workplace culture. When the patterns and practices of the management team demand that heads roll when mistakes are made, blame is the obvious solution. It allows you shift the burden of responsibility to someone else, forcing them to defend themselves from an attack while you retreat to safety.

Blame Never Helps Anything

Blame may solve the immediate problem of your head being on the proverbial chopping block, but it never solves the actual problem at hand. If anything it tends to distract from the issue as the discussion changes from “what went wrong” to “who caused this?” A challenging situation becomes even more complicated as strong negative feelings start to emerge.

Another effect of blame is that people feel alienated and attacked. Team members disengage, afraid to speak up or make changes because they may be attacked for doing so. In this way it damages the innovation and progression of your people, product, and entire company. Blame holds your entire organization hostage.

It’s not hard to see that a workplace which embodies blame culture is really the root problem in-and-of itself.

Accountability

Unlike blame, accountability is assigned internally – it comes from within. It is a positive force of empowerment that requires courage and compassion. Accountability allows people to take control over themselves and their own actions. It destroys “fault” culture while building trust and communication channels with other team members. Statements like “that was my fault team, sorry about that” are welcomed and encouraged, but not necessary.

Accountability can only thrive if the workplace culture is tolerant and accepting. In a blame culture, accountability cannot exist. The mere act of owning up to a mistake assigns the blame to you, and scrutiny and / or punishment is sure to follow. A good work culture is intolerant of blame, instead focusing on people learning from their mistakes and growing as professionals.

A Blameless Workplace

My personal take on accountability as a manager is that “everybody makes mistakes, and as long as you make new and interesting mistakes – rather than repeating them – you have nothing to worry about.”

Mistakes are normal; we all make them regularly. A workplace culture that understands this fact and incorporates it into professional and personal development is one that succeeds with vibrant and engaged teams. Allow people to make mistakes, and follow-up only if they do not learn and grow from those mistakes. Shut down any and all blame conversations immediately. Communicate the difference between assigning blame to someone for their mistakes, and taking ownership of those mistakes themselves. Foster a workplace culture that is blameless.

At Stack Overflow, we do this via a tool that we call the Wheel of Blame. When something goes wrong, anyone in a company chat room can say “not my fault” to spin the wheel. The wheel arbitrarily picks a person from those present in the room and blames them. With blame quickly and definitively assigned, we then move on to fixing the problem.

The Wheel of Blame in action. I'm bad at making gifs so it's not quite right but whatever, I tried.

The Wheel of Blame in action. I’m bad at making gifs so it’s not quite right but whatever, I tried.

Creating Accountability

Despite the Wheel assigning blame – which clearly goes against the blameless culture which I described earlier – this tool is very powerful. It’s a clear and obvious signal to seasoned and new employees alike that we don’t care about blame. When someone is randomly assigned, it’s almost always the case that the problem wasn’t actually their fault. More often than not they had nothing at all to do with the current situation. An ironic and hilarious side effect of the Wheel is that when it does randomly assign the blame to the person who is accountable to the issue, it results in uncontrollable laughter and joking. This alone makes the Wheel worth using: it lightens the mood and communicates our rules around blame in a tribal way (there is no policy written anywhere).

To shift a culture from blame to accountability, begin by shutting down blame discussions. Explain that blame is not helpful, and that the team needs to immediately focus on resolving the issue at hand. Once the problem is solved, consider doing a retrospective which explains what went wrong and who was involved. Circulate this retrospective to any and all interested parties with the clear intention of spreading information, not assigning blame. This allows people to learn and grow from what happened. Continuing this pattern will slowly shift the team away from blame. The trick here is that you don’t have to work on accountability: it will naturally follow when people stop fearing blame.

I encourage you to work towards a culture of accountability on your development team, starting today. Sometimes this transformation can be very difficult to accomplish; particularly when the blame culture starts at the executive level. Nonetheless, do what you can to change the behavior in the part of the company that you influence. Your peers and reports will thank you for it.

Developer Turned Manager

In February of 2015, I was promoted to Engineering Manager at Stack Overflow. This has made a lot of people very angry and been widely regarded as a bad move.

There are tons of things I’ve learned so far, some of which I’ve learned the hard way. There’s also a world of difference between managing code, and managing people who code. Your day to day work routine changes completely. You define success differently. You feel a little bit like you just rebooted your career and are starting over at the bottom of the skills ladder. It’s intimidating.

I’m going to discuss my experiences and insights over the last 6 months as a new manager. This one goes out to all of the developers out there who wonder what it’s like to be a manager, or are considering taking the leap into the realm of Pointy Haired Boss.

Trust is the most important thing

To be a successful manager, you must earn the trust of your team members. People won’t work for someone that they can’t trust. Combine this with the fact that a large reason that people leave their jobs is their boss (even above money, benefits, commute, or vacation), and it’s clear that this is your biggest priority as a manager.

Trust is earned, not given. A manager can’t talk people into trusting them; you have to show them that you can be trusted. In my experience, the time it takes to earn trust varies from employee to employee. I had the advantage of having already worked with my employees for almost a year, so some people trusted me on day 1 as a manager based on prior interactions. Others took a few weeks or even months to come around. The important thing to realize is that you can’t rush developing trust. Patience is key.

To earn your team’s trust, you must demonstrate good professional and personal character:

  • Hold everything told to you by employees in confidence. Don’t gossip or talk about employee issues with other employees.
  • Have an “open door” policy: make it clear that people can talk to you about anything, at any time that you’re free.
  • Be a person of your word. Say what you mean, and do what you say.
  • Don’t promise anything that you can’t deliver on. It’s better to say “I’ll see what I can do, but no promises” about a raise, promotion, or bonus than to say “sure we can work that out! No problem!” and then not deliver.
  • Never lie to anyone. Being a liar in the eyes of your employees is the fastest path to failure. They will not only distrust you, but actually start avoiding you as well.
  • Be direct with your people about things that you need to address, especially when it’s uncomfortable to do so. Don’t dodge subjects. Don’t avoid elephants in the room. These problems grow and only get worse if left unresolved.
  • Never be passive-aggressive. Don’t gossip about people. Don’t talk about person A to person B behind their back. It’s important to have an outlet to vent, but make that outlet your spouse or family in complete confidence – not your employees.
  • Praise publicly, punish privately. Never alienate someone in front of the team.
  • Be as objective and fair as possible at all times. Don’t give anyone special treatment or status.

All of these things (and more) are essential characteristics of a good manager.

Code scales, humans don’t

The great thing about code is that when written properly, it scales very well. The same code can easily handle both the 1 user case and the 100,000 users case if it’s efficient and optimized. As a developer this is what we aim for, and it’s easy to measure.

A manager, however, doesn’t scale. The work is done on humans, not computers, and human interactions don’t scale. Just imagine trying to reach consensus on a subject in a meeting of 20 people. It’s much easier to do in a room of 10 or fewer.

No manager can effectively manage 20 direct reports. In fact, people experienced in the field feel that 4-10 employees is the maximum. It’s important to recognize that you can’t get stretched too thin; this will cause you to pay too little attention to your employees and make them feel resentful and unimportant. It will also prevent you from getting any work done. If your team grows too large, split them up and get another manager on board to share the work.

Make people a priority

As a developer, people were an interruption and distraction to my work. As a manager, people are my priority. You must always prioritize people. Not just your people, either. It’s not uncommon for people from other teams to want to talk to you for an outside perspective – make those conversations a priority as well. This means being flexible: if they want to call you and chat at 5pm on a Friday, try and make it happen. If they work in another time zone and want to meet at 7am on a Tuesday, get up early and do it.

Another important aspect of prioritizing people is having a regular 1 on 1 with each of your employees. The 1 on 1 is your employee’s safe place to talk. They will tell you about what’s going on, bring up personal or professional issues, or give you feedback on things that you can do better. I have a recurring 45 minute meeting with each of my employees every 3 weeks. They have been incredibly valuable to me so far.

Make an effort to be organized and use your time effectively. Do everything that you can to avoid rescheduling, being late for, or missing a 1 on 1. If you do this regularly, your culture and morale will suffer greatly. Nothing says “you’re not important” more clearly than missing or rescheduling a 1 on 1 for no good reason.

Embrace uncomfortable conversations

As a developer I sometimes found myself gossiping about, or venting to, other developers about people and policies that were annoying me at work. As a manager, your job is to help people address their problems with each other directly. Encourage people to approach the other party to address their concerns, rather than gossip or vent to co-workers. Be sure to lead by example and practice this consistently yourself.

When someone comes to you with an issue they’re having with someone else, get both parties into a private room with you. Mediate a constructive conversation where they directly discuss their feelings and resolve their concerns. These situations can be awkward and uncomfortable, but you must embrace them and make them a part of your culture. Do this consistently until people start doing it without involving you at all. Make sure that you don’t let problems go unresolved; they only get worse with time.

Success is really hard to measure

The great thing about being a developer is that you usually have a specific problem to solve. “The application needs to do this new thing,” “Fix this bug,” and so on are well scoped problems. When you finally complete the work you get the satisfaction of having accomplished something. You might even get some accolades in a team meeting or town hall.

Management is not a race but a long-distance marathon. You will not be crossing any measurable finish lines anytime soon. As a manager, your work is in affecting the often-intangible aspects of human beings: their thoughts, feelings, soft skills, and overall growth. These types of progress are on-going and arguably never-ending. We are never truly finished growing, learning, and bettering ourselves.

Instead of “fix this bug,” a manager’s task is “help Person improve their interpersonal communication style” or “grow Person’s soft skills so that they can be promoted in a year” or even “figure out a way to help Person get to work on time more often because they keep sleeping in.” None of these are break-fix problems, and thus it’s rare to feel like you’ve succeeded or finished something you’re working on. I find that feelings of success come from the feedback of others: an employee thanking me for some great advice or feedback, someone telling me they’re noticing a positive change on my team, or even a “keep up the good work!” from someone outside of your team. Nothing feels better than knowing you’re making a positive impact in the day to day of your people, but it again requires patience to see results.

Nobody sees you do work

As a developer, your work is done overtly. You’re a better developer for being outspoken about what you’re working on, and creating transparency so that anyone – from other developers to the CEO – can see what you’re working on and what’s getting accomplished. It’s easy to show that you’re doing some real work.

As a manager, almost all of your work is done behind the scenes. As a result, being a manager becomes this “out of sight, out of mind” thing where some people will perceive you as doing very little work. This is because when I talk to an employee about their communication style and issues they’re having interacting with others, I do it privately. It’s not as if I can send a status report e-mail to the team that says “I had a chat with Person about their communication issues, high fives everyone!” As a result, nobody other than the person I talked with directly knows that the interaction happened. Thus, to others, it might appear that I never addressed the issue.

The way that a manager shows that they’re doing work is in observable team member improvements. It’s a slow process (like many things management), but it will become obvious that you’re doing good work when the team starts to notice that Person is interacting in generally more positive ways, or on time for work more often. As your people grow and develop, your team will become stronger and more effective; people may remark on your team’s positive changes as well.

Ultimately, your success is the success of others

If you’re in it for the praise, you’re gonna have a bad time. Management is about trust, having direct and sometimes difficult conversations, and doing your work behind the scenes but in direct and fair ways. It’s a very empowering, challenging, and rewarding job that I’m enjoying immensely.

One of my favourite quotes from Futurama was pretty much written for managers, so I’ll leave you with this:

“When you do things right, people won’t be sure you’ve done anything at all.”

The Recruiting Competitive Advantage

Let’s say you were walking down a street one day and noticed an ad for help wanted. It is posted in the window of a bakery. It reads:


HELP WANTED:
Need a baker for FT work. Must be familiar with modern baking methods such as ovens, barbecuing, and deep fryers. 5+ years experience with the Super 6 commercial baking oven required (aside: came out in 2014). Nice to haves include experience with butcher’s blocks, chopping meat, and making candles.

Given that most of us understand the high-level job of a baker pretty well, it’s easy to see how totally ridiculous this job listing is. Let’s break it down:


Need a baker for FT work.

Doesn’t say too much, but it makes sense and describes your need accurately.


Must be familiar with modern baking methods such as ovens, barbecuing, and deep fryers.

Most bakers would be familiar with ovens, but no baker in their right mind would ever “bake” with a barbecue or deep fryer. At this point we begin to question whether or not this bakery has any idea of what it’s doing at all.


5+ years experience with the Super 6 commercial baking oven required (aside: came out in 2014).

Well, they want me to have 5 years of experience (or more) with an oven that has existed for only 1 year? That’s just silly. Now I think that they’re sort of out to lunch and don’t really want to work here.


Nice to haves include experience with butcher’s blocks, chopping meat, and making candles.

A baker is a very specialized position. There’s rarely going to be one who has specialized in not just baking but also butchery and candlestick making (catch my sly joke there?). A place asking for all 3 is really asking for 1 person to do 3 jobs for the price of 1 job. This isn’t fair and further dissuades the candidate.

This job posting sounds funny because it’s plain to see just how insanely off-kilter it is. However, recruiters are out there right now posting tech job listings that are just as ludicrous. The problem is that they haven’t bothered to learn much about the field that their job is focused around. So, they end up sounding as silly as the bakery owner does above.

Recruiters: this is how silly you sound to developers when you post a listing full of jargon that you don’t understand. Most of us don’t want to ever work on both C# and Java at the same time, and the odds of finding both an iOS and Android pro in one human being are slim-to-none.

All that is required for a recruiter to gain a significant competitive advantage over their peers is a little knowledge. Knowledge that could be learned in weeks. Knowledge of a standard tech stack, and the ability to Google technical acronyms like MVC and EF when they show up. If you just took a little time to make sure that your job listing was not a walking contradiction – full of statements that counter each other, technologies that don’t work together, and demanding 5+ years of experience on things that have existed for less than 2 years – you’d have a huge leg up on your peers.

Developers are rational, logical people. We will engage in the jobs that make sense. If your listing is irrational or illogical, we will avoid you like the plague. We will also make fun of your job listing to our friends, especially when you spammed e-mailed us with it directly.

So, if you’re a recruiter reading this, and you want to get ahead, it’s very simple. Learn the tech that your listing is based around at a high level (in my opinion a basic proficiency of your profession), or failing that, consult a developer to make sure that your listing doesn’t sound crazy!

On Credentialism In Software Development

We’re just two days from a brand new year and yet the primary measurement of a developer’s skill seems to be the same as it was 20 years ago. The most important classification to most companies is job title, as I talked about in great detail in my last post. The job title is acquired via working for a veritable slough of credentialist companies whose HR departments break it down very simply:

  • You’re a Junior Developer if you have 0-2 years of professional experience
  • You’re a Developer if you have 2-5 years of professional experience
  • You’re a Senior Developer if you have 5+ years of professional experience
  • You’re a Team Lead, Architect, or Manager once someone promotes you from Senior Developer

The problem with this sort of classification is obvious. The truth is that one person has 10 years of development experience, and the person standing next to her has 1 year of development experience repeated 10 times. The people that end up in the latter category tend to be “company [wo]men” – the ones who stick with a job forever and never try something new.

I am not one to believe that rockstar developers are valuable. As Scott Hanselman writes, rockstar developers do much more harm than good. I do, however, believe that the proper classification of developer skill lies in my paraphrasing of Nate Waddoups’ description:

  • A Junior Developer creates complex solutions to simple problems. You see these people across all companies and in all kinds of positions: from Junior Developer to CIO. They take a one-off batch service that processes requests and make it into a 40 class, 2000 line monster that involves a ServiceFactoryFactory and a ServiceDecorator.
  • A Developer creates simple solutions to simple problems. They’ve gotten past the pattern-itis and realize (for the most part) when to use design patterns, and when to just write simple code that works. These people tend to write the batch service in 100 lines and it works correctly 99% of the time (and is easy to maintain too).
  • A Senior Developer creates simple solutions to complex problems. These people have begun to truly master the art of software development and can whip up a highly scalable e-commerce app in fewer assemblies, classes, and lines than most of us would have used to create “Hello World” as a Junior Developer. They would be incredible role models if only they’d drop the ego.
  • A Truly Exceptional Developer is a rare thing. They don’t just make complex problems simple – they make complex problems disappear entirely. These people wield code like I imagine ancient Samurai wielded the blade: with great precision and skill. They dropped their ego years ago. In doing so, they empowered themselves to continue to learn from others which ultimately caused them to excel far beyond their Senior Developer peers. They are incredible role models and all around must-haves on any high performance team. They love to teach as much as they love to learn.

Notice that I never gave a time frame to any of these levels of skill. I don’t believe that 1 Truly Exceptional Developer can be faster than 10 Senior Developers. I do believe that in the long run they save you 10x your time and money. They write extremely maintainable code which has few bugs and even fewer scaling issues. They can quickly learn and do anything asked of them. They are truly versatile and efficient.

What would be required for companies to finally start hiring based on skill as opposed to credentialism? The reality is that some already do. To hire skill takes nothing more than ignoring the number of years of experience written on paper and simply administering a few code tests to a candidate that appears to have the desired personality traits. These tests should be moderately difficult and focus on a problem that has many answers – only a few of which are good.

A great example (though well known at this point) is the FizzBuzz test:

Write a program that counts from 1 to 100. If the current count is evenly divisible by 3, output “Fizz”. If the current count is evenly divisible by 5, output “Buzz”. If the current count is evenly divisible by both 3 and 5, output “FizzBuzz”. Otherwise, just output the current count.

This task is fairly simple but has many solutions – only a few of which are good. In tasking a candidate to complete FizzBuzz, their skill (or lack thereof) will show itself immediately:

  • The Junior Developer will write a whole ton of if statements, possibly even hard-coding all of the multiples. This section of code is probably in its own class, injected via the constructor and provided by the DivisorCounterFactory. Also, there will be as many lines of comments as there are code.
    // Count to 100
    for (int i = 1; i <= 100; i++)
    {
        if (i == 15 || i == 30 
            || i == 45 || i == 60...)
        {
            // Write "FizzBuzz" to the console
            Console.WriteLine("FizzBuzz");
        }
        else if (i == 3 || i == 6 
            || i == 9 || i == 12...)
        {
            // Write "Fizz" to the console
            Console.WriteLine("Fizz");
        }
        else if (i == 5 || i == 10 
            || i == 15 || i == 20...)
        {
            // Write "Buzz" to the console
            Console.WriteLine("Buzz");
        }
        else
        {
            // Write current count to the console
            Console.WriteLine(i);
        }
    }
    

    This is not a very scalable way to solve the problem.

  • The Developer will whip together a few if statements using modulus to solve the problem.
    for (int i = 1; i <= 100; i++)
    {
        if (i % 3 == 0 && i % 5 ==0)
        {
            Console.WriteLine("FizzBuzz");
        }
        else if (i % 3 == 0)
        {
            Console.WriteLine("Fizz");
        }
        else if (i % 5 == 0)
        {
            Console.WriteLine("Buzz");
        }
        else
        {
            Console.WriteLine(i);
        }
    }
    

    Decent solution, fairly simple and by-the-book answer.

  • The Senior Developer will realize that they can combine the statements.
    for (int i = 1; i <= 100; i++)
    {
        string result = "";
        if (i % 3 == 0)
        {
            result += "Fizz";
        }
        if (i % 5 == 0)
        {
            result += "Buzz";
        }
    
        Console.WriteLine(result.Length > 0 ? result : i.ToString());
    }
    

    Clean, simple code that takes up maybe 10 lines when you get rid of my Allman style code indentation. Then, if the ego remains, they’ll ask you why you make developers jump through interview hoops, and possibly berate you for wasting their precious time and skills on such a remedial task.

  • The Truly Exceptional Developer, having never before heard of the FizzBuzz problem, will write the Senior Developer solution in a matter of 2 or 3 minutes. They’ll then discuss the ways in which it could possibly be improved. Things like how a case statement might technically be faster than an if statement in some cases due to omitting an op code at the assembly level, or how to optimize appending immutable strings together in order to avoid creating additional objects which would later have to be garbage collected. They’ll thoroughly enjoy the problem and be enthusiastic in the discussion.

A 30 minute code test immediately gives you more insight into the candidate’s skill than a whole day of discussions ever could. You can proceed to hiring with confidence (perhaps after a few more code tests administered by different people in order to observe the candidate’s ability to work with others). You can also reject a candidate with confidence. No matter how good of a salesperson they are, they will not be able to talk their way past the code test.

In summary, my unsolicited advice to you is this: if you want to work with good developers, just reject any interview process or job offer that doesn’t involve a code test. A lack of code testing means that all manners of developer will slip through that company’s hiring process (including those at the very low end of the bell curve) and that they will be your coworkers.

Via this hiring approach, you’ll meet Junior Developers with 25 years of experience, and Truly Exceptional Developers fresh out of school – and everything else in between.

Doesn’t it seem obvious that we should be tested on our coding skills, given that coding is literally the primary task that we are hired to do for 40+ hours a week? Do you think that a hospital would hire a surgeon without testing their skills? Would the NFL or NHL recruit a player without testing their skills (or at least seeing their skills in action)?

In all professions, the top tiers test their candidates for practical skills. This filters out the unskilled, resulting in awesome teams of incredibly skilled people. These are the teams we want to be on. These are the companies we want to work for. These are the environments in which we learn and become Truly Exceptional Developers.

PS – I hope that you had a terrific Christmas and will have a Happy New Year!

The Trouble With Job Titles

I’ve had a good career so far. I began working full-time as a programmer in 2008. At that time my title was Junior Developer. I had a decent boss and cool co-workers, and I cut my teeth on Java and .NET. It was a good experience. After 2 years at that gig, I felt that it was time to move on.

I contacted recruiters, and one eventually found me a promotion: Systems Analyst. It came with a decent pay bump and so forth, as well as the luxury of dropping “Junior” from my job title. As this was a good deal all around, I took the offer.

A few more years went by and I found myself once again looking for “the next step” in my career. Lo-and-behold my current company had appreciated my skill as a Systems Analyst and wanted to bring me on as a Developer. Before I knew it I was a .NET Developer which, as my other job changes had previously, came with a pay raise and better perks. Things were going great.

I did 3 years total with this company, during which I was promoted to .NET Development Team Lead – a terrific title in the realm of programming. I ran a small team of 4-5 people and things were going pretty well.

Eventually, having maxed out my skills and knowledge at this company, I moved on. I became a .NET Architect with appropriate pay and benefits. It was a reasonable gig.

This is where I’ll introduce a sideline fact: during my entire career to this point, recruiters (both in-house and third-party) had been cold-calling and contacting me with jobs that matched my current title (with more contact as I got further in my career). As a .NET Development Team Lead, I was offered jobs that ranged from Senior Developer to Team Lead to Architect. As a .NET Architect, I was offered titles from Team Lead to Architect to Manager. So far things made sense.

About 5 months ago I took a job with a company that I love, Stack Exchange. Things are going great so far, and I’ve never been treated better in my entire development career. My pay and benefits are top-notch, my job perks are incredible, and my boss is a genuinely competent, solid human being – as are all of my co-workers. It is the current high-bar of my career track record.

Where it becomes interesting is in my job title. At Stack Exchange I am a Web Developer. That’s the whole title. Not Manager, or Team Lead, or Architect, but Web Developer. The reason for this is that Stack Exchange is not a company that cares for credentialism. We hire smart people who gets things done (their words, not mine) and developers here handle projects from start to finish. This means that we sometimes act as a Manager of others, sometimes a Team Lead of others, and often an Architect as we discuss and debate the best way to solve a particular problem or design a particular system.

It was not until I got this job that I realized how broken the current recruiting industry is. Just 6 months ago I was receiving cold calls and offers to interview for Team Lead, Architect, and Manager jobs (with expected pay). Can you guess what jobs they contact me with these days?

Junior Developer and Intermediate Developer. Complete with massive pay and benefits cut. Offering these positions to me is a complete waste of both my time and the recruiter’s.

It’s pretty obvious why this happens: recruiters are usually not contacting me personally based on researching my career and goals. They are contacting me as 1 of 10-50 others that they will contact via cold-call or e-mail on any given day. A shotgun approach of “fire it off and see what hits” as it were.

I am certainly not egotistical enough to be offended by being offered titles and pay well below my current skill set. What does bother me, however, is the fact that I cannot convince most recruiters of anything otherwise. I took it upon myself to explain to one recruiter that Web Developer at Stack Exchange is about the equivalent (in my opinion) of a Team Lead or Architect at many other companies. Their response was that if that were true, it would be my title here. I was dumbfounded.

Given that there are no current standards for developer titles, it is plain to see that a Developer at Company A could be anything from a Junior Developer to CIO at Company B. It’s a crap shoot. Especially when you consider the fact that some companies inflate the titles of their employees as a “free” form of making them feel valued (as opposed to, say, paying them properly).

I don’t know what the solution is to the recruiting industry’s problem, but it does make me realize the value of Stack Overflow Careers. We match candidates with jobs based on experience, interests, and open source projects, not via titles and credentialism. We explicitly ban companies that spam candidates with a job offering. This means that every single message written to you as a candidate is personalized and written by hand by the recruiter. Very few recruiting companies can claim similarly. We continue to evolve this product, and I hope that one day it sets a new standard for recruiting where people don’t blindly call you up with jobs that match your current title.

This lack of standards is a difficult problem to solve. I don’t pretend that I have the answers. It does show me precisely how you end up working with incompetent people though.

John Doe is an incompetent developer who works for a small dev shop that gives him low pay but a big title such as Senior Developer. A recruiter eventually offers this developer jobs of a similar title but that have the appropriate pay. John jumps at the giant raise and heads to the next company. What happens next is something we’ve surely all seen a few times… John can’t hack it, John gets 3-6 months in and gets let go. John was cheated by the system of credentialism. Who can blame him directly for grabbing the highest value offering he can get? We all would.

This broken system wastes time, tons of money, and screws up company culture. Nobody likes working with John as a peer when he knows 1/10th of what they do, does even less work, and gets paid the same or better. That causes your good developers to run for the hills, and your workplace culture to suck as another John fills the now open role of a good dev.

The current state of the recruiting industry is fairly toxic. Most recruiters will put anyone anywhere to make a buck and meet their draw or quota.

The question becomes: how do we, with Stack Overflow Careers, completely dismantle this system and rebuild it properly? Time will tell, and I’m excited to see the results.

How I Got A Job At Stack Exchange

Almost exactly 1 month ago today I found myself on a video call with Joel Spolsky. It feels insane to write that, even now, as it was a banner moment in my career. For me it was the equivalent of meeting a movie star who I had idolized since I was old enough to know what movies were. There had always been this Joel Spolsky guy throughout my career that I regularly read about and whose opinions on software development agreed with mine, and suddenly I was talking with him face to face. It was awesome.

Reaching this conversation was not the easiest thing I’ve done in my life. It took a few weeks and in all honesty it was a bit trying to find time to have so many interviews. How many interviews, you ask? Prior to Joel I talked with 5 or 6 other amazing people (Marc Gravell and Nicholas Larsen included). Somehow I managed to impress each of them enough to reach the end boss: Joel Spolsky.

The conversation lasted about an hour. It felt like 5 minutes to me, probably because of the excitement. Joel and I discussed the pros and cons of various software methodologies, mistakes each of us had made in our careers, some of the challenges of Dache (my open source software), and a few other topics. Then he said something awesome: “We’d love for you to come and work with us at Stack Exchange!” So much adrenaline hit me at this moment that I could have lifted a car with my bare hands. It was surreal.

A few days from now I officially start working with Stack Exchange. I feel very fortunate and excited for the opportunity. So far the Stack Exchange team have proven themselves an insanely skilled and professional organization that treat employees as human beings instead of expendable resources. I’m already loving the culture and interactions with my coworkers.

IMPORTANT NOTES: First and foremost, the commentary here consists of my views alone and not those of Stack Exchange or any other entity. This post is merely to reflect upon the interview process and discuss the aspects and traits of my career and knowledge which I feel helped me get the job. This is not a tell-all or any sort of shortcut or easy way out. If you want a job at Stack Exchange, you will have to endure the same technical and soft skills challenges that I did – the details of which I will NOT be disclosing. 🙂

So, with that disclaimer out of the way, here are my thoughts on how I got a job at Stack Exchange, and how you can too:

Ego is the mind killer, so kill the ego. Most developers that I’ve met (including some prior versions of myself) have massive egos. Egos so big that the room can barely hold them. Egos that even put the illustrious Kanye West’s attitude to shame. This is natural given that we spend all day creating things from scratch (which is a god-like quality) that often generate significant revenue for companies. We start to feel very powerful and even fawned over. We learn the entirety of the software and hardware vertical of our current job’s domain, and then make a Superman-like flying leap to conclude that we know EVERYTHING about ALL software and hardware.

Thinking you know everything is the easiest way to suck as a programmer. If you believe that you know everything, you stop trying to learn new things (since you already know them, duh). So, while you’ve mastered ASP.NET MVC 3 at your current gig, 4 and 5 came out… the catch is that your company never upgraded because it’s too risky, and so you never learned them (or cared to). Now a year or two later you’re so far behind the current development stack that you can’t even see it with binoculars. And did I mention those little things called Ruby and PHP and even Java that you’ve never written a single line of? And how about MongoDB, Couchbase, Azure, EC2, and the literally thousands of other platforms and programming languages? I should hope that by now you realize that you know a little bit about a handful of languages and hardware configurations amidst a sea of thousands… By percentage, you’ve conquered maybe 0.1% of all that there is to know about development. So have I, and that’s OK.

Don’t be a rock star developer. This is something that I did for a few years and it only hurt my career. Many companies employ a strategy of intentionally furthering the developer ego in order to make them feel valuable (often without handing out appropriate compensation). Being a rock star sounds cool, but really it’s a nasty strategy that can cultivate incredibly destructive developer attitudes. Companies seek out and hire rock stars, and rock stars have a sense of entitlement. They develop huge egos and run their mouths at meetings, interrupting and talking over others. They seem to love circular logic (they’re right because you’re wrong because they’re right). They feel that all other team members exist simply to serve their every whim… and everyone loathes working with them.

The thing is – while you may actually be a 1 in 1 million bona fide rock star developer – nobody cares. Talk is cheap and in my experience people will say nearly anything and everything to portray an image of who they want you to believe they are. If you are really good at what you do, telling people doesn’t do anything other than make them despise you… Hearing about how amazing your proprietary code is gets annoying – especially when it’s the 5th time this week you’ve said it. A good developer doesn’t need to brag about how good they are: their work speaks louder than any boastful words could. People around them will naturally do the bragging for them. Hallway conversations to the tune of “wow, he’s really smart” or “she knocked that out in hours when we thought it’d take days” will be fostered, and that isn’t a bad thing. Let people talk about you all they’d like, but maintain a sense of humility and reality. You might be the best developer on your team or even at your company, but you are still a human being and this is still a job. Nobody has been hired to serve your ego (even if their job is to serve you). Being a good developer doesn’t make you better than anyone as a person; it just makes you successful in your career. Never lose sight of the fact that thousands of other developers are great at their jobs too. What separates you from the pack is being a great developer AND modest. It is a very rare combination in my experience, and the complete package that many companies are striving to hire. So, while it’s cool that you’re the very best developer that there ever was, stop believing your own hype and telling everyone who will listen. They don’t care, and you shouldn’t either.

Know that you know enough to know that you don’t know enough. Know what you do know, and know what you don’t know, and never be afraid to say “I don’t know” when it’s the truth. A developer who isn’t afraid to say “I don’t know” in front of a room full of people is a rare gem. By being honest you create trust and credibility. You also foster positive relationships with your peers and company. Nobody will remember that you’ve never heard of Angular.js or Couchbase, though they’ll always appreciate that you didn’t waste their time or money by pretending that you did. You can’t trust a developer who doesn’t know what they don’t know.

Know your data structures and algorithms. High level programming languages such as C# abstract so much away from the modern developer that many of us have no idea what’s actually happening “under the hood” when it executes. It’s cool that you can sling LINQ everywhere, but do you know the computational complexity of what you’ve done? Do you know what a hash table is and why it is useful? Could you sort a list of things efficiently? Can you think of a scenario where a stack is the best option? Note that you don’t need to memorize things like sorting algorithms (hell, I couldn’t if I tried), but a working knowledge of data structures such as trees, hash buckets, lists, queues, and stacks combined with the rudimentary knowledge of things like sorting, searching, and caching is a very valuable skillset. It’s the difference between a good programmer and a great one. Anyone can write C#, but only those who understand even the low level operations of each deliberate method call will write good, clean, efficient code. You owe yourself a fundamental understanding of how data structures like stacks and heaps work, as well as by-value vs by-reference memory addressing. These core concepts apply to ALL programming languages. Too many developers ignore the complexity of their algorithms and just call pre-made methods without understanding the implications. Educate yourself on data structures and algorithms and suddenly you’ll be ahead of the pack.

Know why your code works and why your code doesn’t work. Have you seen this image circulating on sites like Reddit?

Clueless

Despite being funny, the popularity of this image pisses me off. It claims that the essence of programming is having no freaking clue why your code does or does not run. I feel that this is unacceptable. A great developer strives for the WHY in every single thing that they do, not just HOW to quick-fix it. Code doesn’t compile? WHY? Race condition across threads? WHY? In asking “why” you further your knowledge and expand your skillset with the functional, rational “how” which allows you to become a better programmer. Most great programmers don’t repeat the same mistakes over and over, though they of course make mistakes… They just make new and interesting ones!

I remember the days of slinging shoddy code and then copy-pasting lines from blogs and sites like Stack Overflow until my code seemed to work (though I wasn’t sure if or why it did). Those days are long behind me. When my code doesn’t compile, 99% of the time I immediately know how to fix the issue. When my code has a bug, I usually know exactly how to track it down and resolve it, and in doing so I often learn how to avoid it in the future. Having no idea why your code works is like being a lawyer who has no idea why their client is not guilty: fairly useless, overpaid, and an amusing spectacle at times. Make sure that you know why your code works and why it doesn’t. In my opinion this is a basic competency of being a professional developer. It’s OK to create bugs and make mistakes – it’s not OK to make the same mistakes repeatedly.

At this point I feel that I’ve done a reasonable job of representing my skillset and core competencies. These are the things I showed to the Stack Exchange team in my interviews. I didn’t necessarily have the exact answer (or even most efficient answer) to each of their technical questions, but I was modest and never afraid to ask for help or say “I don’t know” when I got stuck. My answers involved efficient data structures and algorithms, and I was able to explain why the data structure was the best choice in solving the problem. When I created bugs I was mostly able to identify them and indicate how to fix them. In doing all of this, I demonstrated competency and confidence as a developer and fortunately ended up with my dream job.

If you think you’ve got the chops to join us at Stack Exchange, apply today!

Time to Try Something New

I read a lot of other programming blogs. After all, gathering information from multiple sources is a great way to get a rounded education. Every so often, the author of a blog gets a new job and writes a blog post about the transition to the new job and rationalization of leaving the current job. I’m certainly not against such posts (I definitely read them) but I must admit that I don’t feel that they actually contribute anything useful to anybody other than the author. I believe that each person is unique, and their career is a personal, private, proud, unique part of them. People typically do things and make decisions during their career to further themselves. Some of these actions and decisions end up being good and others bad. However, regardless of outcome, the decision or action is made for reasons that are entirely the person’s own and relative to their unique circumstance. What motivates person A to work at company X won’t motivate person B and so forth.

So while I enjoy reading posts that explain how the author feels that they’ve been at their job for too long, or they aren’t yet on the latest .NET framework and are falling behind, or they feel that getting into a new industry or vertical is a good idea, the reality is that these reasons are them rationalizing the decision to themselves. The post as a result is self-serving… As is mine that you’re reading now.

In light of this mindset, I will keep the actual announcement part of my “new job” post short and sweet.

While I had a great time working with Fanatics and helping them grow from a brick-and-mortar sports store to the e-commerce platform that hosts such juggernauts as the official NFL, NBA, NASCAR, MLB, NHL, and ESPN stores, it is time for me to move on and do something new. As of Monday, September 30th I’ll be working at iMobile3 – a mobile application and wallet/payment service company based out of Jacksonville. I am extremely excited to be able to contribute to such an interesting product and to have the opportunity to have a direct impact on the company’s future successes and growth.

Here comes the next adventure; a new experience and opportunity. I’m very excited.

The Joel Test Really is Meaningful

Well, it’s been nearly 2 months since my last post… I’m learning that if you want a blog to be successful, you have to carve time out of your busy life and make it happen. So, with renewed focus, I re-enter the fray.

The Joel Test is a curious and honest thing. It has been around since the year 2000 and was invented by a guy named Joel Spolsky, as the name might imply. In short, it’s a very brief questionnaire that evaluates the quality of your software development team, and implicitly their happiness as well.

There are 12 questions. A score of 12 is perfect, 11 is good, 10 or lower and your team has serious problems. The questions are simple and in the format of yes/no. The Joel Test is as follows:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

For those who have never heard of hallway usability testing, I offer Joel’s definition: “A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.”

The Joel Test has been in and out of my life for quite some time. Every now and then I remember that it exists, and then I evaluate my current employer on it. My current company is suffering in the programming department; we are losing people like crazy and are having a hard time hiring good folks, despite offering reasonably competitive salaries and benefits… So, realizing that we have some issues, I conducted The Joel Test on a whim. Here’s how we did:

1. Do you use source control? Yes.
2. Can you make a build in one step? Yes.
3. Do you make daily builds? No.
4. Do you have a bug database? Yes.
5. Do you fix bugs before writing new code? No.
6. Do you have an up-to-date schedule? No.
7. Do you have a spec? No.
8. Do programmers have quiet working conditions? No.
9. Do you use the best tools money can buy? No.
10. Do you have testers? Yes.
11. Do new candidates write code during their interview? No.
12. Do you do hallway usability testing? No.

We scored 4. 4 out of 12. Recall that 10 or worse means that you have a serious problem. Yeah.

So, what did I learn? I learned that part of the reason that we are losing people is that our programming practices and team environment lack something to be desired, and thus people are not happy. This isn’t really news to me, however, since the people that have quit recently have all cited these things as some of the main reasons.

What’s the next play? We need to improve the aspects of our environment and team that failed the test. The question then becomes: will management improve these things, or will they choose to ignore our suggestions because most of them (using the best tools that money can buy, quiet working conditions) cost money, and the rest of them are process changes? In fact, I’d go so far as to say that for my current company, they’d be significant process changes… And if there’s one thing that I’ve learned in my career as a programmer so far, it’s that businesses love to stay in familiar territory, clinging to what they already know and feel experienced in, and are generally afraid of significant change.

As a result of the change not being delivered, the motivated individual realizes that change must then come from within… People quit to change the negative environment for themselves (by joining a more positive one).

I encourage you all to conduct The Joel Test in your environments, and to try and improve your team with the results. What have you got to lose? Oh yeah, more developers. 😉