Professor Beekums Blog

Follow Professor Beekums
follow professor beekums on twitter like professor beekums on facebook

Sunday, January 22, 2017

How Do You Know A Developer Is Doing A Good Job?

Evaluation of developers is an important topic for anyone involved in software development. Many developers care a great deal about career growth or raises at the very least. Managers need to be able to justify decisions around promotions and raises.

Ideally, developers would be rewarded based on the amount of value they provide to a business. It’s a simple concept: you make the company more money, the company pays you more money.

The complexity lies in the fact that the nature of software development does not make it easy to measure the value a single developer brings. If you have a product that has hundreds of features and makes $10 million a year, how do you know how much of that value was attributed to a single feature? Even if you could do that, the feature was most likely worked on by multiple developers. How do you attribute the contribution of each?

There isn’t a good answer to that question. It just isn’t practical to attempt to make those kinds of measurements. What we are left with are subjective judgement calls by managers.

The risk with this approach is that the criteria are vague from a developer’s point of view. They can’t really know what their manager is thinking. There is now an incentive to focus on learning to sell themselves to their manager instead of focusing on becoming a better developer.

An attractive solution to this problem are quantitative metrics. If we can’t measure the exact value a developer brings to the company, maybe we can find something we can measure easily that will be a good indicator of value created?

The most naive measure here is counting the lines of code a developer writes. This may make sense to those who aren’t developers, at least at first. Developers write code… so maybe more code means more value?

The problem here is that high quality code often means fewer lines of code. A really simple example is: Say you wanted to display 100 products on your e-commerce website. You could do something like this:
….97 lines later...
100 products, 100 lines of code!

No decent developer would do this.

They would instead make it 2 lines of code:
for productNumber = 1, productNumber <= 100, productNumber++:
If you paid your developers per line of code, you would reward the inefficient developers.

An analogy to this is writing essays, novels, blog posts, etc. Would you judge a writer solely on the number of words written? Probably not. There are a minimum number of words needed to get a complex point across, but those points get lost when a writer clutters their work with useless sentences. I know I’ve read books that would have been great 3 page essays, but ended up being really tedious books.

So the lines of code metric doesn’t work. The notion of a quantifiable metric for evaluating developers is still attractive though.

Some may argue that creating many code branches is the mark of a great developer. Yet I once worked with a developer who would create code branches to hide the fact that he wasn’t very productive.

Some may argue that you can measure the number of code commits a developer makes. But that just makes it more likely to get lots of really tiny commits that have little to no meaningful changes in them. Or a developer can easily game that by undoing and redoing the same few sets of changes to bring up commit counts.

Maybe number of bugs fixed is the answer? Software bugs can be complicated though. By tying raises and promotions to bug fixes, you create the incentive for a developer to fix apparent issues while ignoring underlying causes. It would be like using duct tape to fix a broken leg. Worst case, you would reward developers who don't take extra care to prevent bugs in the first place.

The real problem with quantifiable metrics like these is that they change the incentive for a developer. While creating business value is the goal, it can be hard for a developer to make it apparent that they are creating business value. It would be much MUCH easier to just optimize for other quantifiable metrics regardless of whether those metrics bring value to the business or not. This is far from desirable for anyone.

We are still left with the challenging question: how do you know if a developer is doing a good job?

In my opinion, the best measures are all subjective:
  • Are they good team members?
  • Can they solve problems?
  • Can they write good code?
  • Are they eager to learn?
  • Can you trust them?
There are others, but the point is that every measure of a good developer is qualitative. That requires managers to communicate frequently with each developer that reports to them. Managers must create a culture where developers can be confident that they will rewarded for doing the right thing, not looking like they are doing the right thing.

Quantitative measures are attractive because they are easy. But nothing about management is easy. If it was, anyone could do it.

Do you have an evaluation method that you think is unique? I would love to hear from you!

Saturday, January 14, 2017

Do Programming Languages Matter?

A lot of attention is given to programming languages. Many companies list positions such as “PHP Developer” or “Java Programmer”. Those interested in learning how to code often ask what language they should learn. Developers themselves argue over the merits of various languages.
Does it really matter what programming languages you know though?

There are a growing number of people, including myself, that don’t take known languages into account when hiring. When interviewing candidates, they are allowed to use any language they want (or even pseudo code). The idea is that we want to test whether a candidate has a good understanding of software development fundamentals. A developer with a strong understanding of the fundamentals will be able to pick up a new language fairly quickly. Someone who lacks those fundamentals will take a lot longer picking them up.

Yet, not all programming languages are the same. Many in fact force you to work in different paradigms than you may be used to. My most commonly used languages for a while were Java, Javascript, and PHP. I was heavily reliant on many object oriented programming patterns that are not possible in Golang. Golang removed those patterns in the belief that there are better patterns that developers should be trying.

At first I thought that Golang was absurd and didn’t think the creators of it made good decisions. After trying it out though, I realized there were some really valid points being made. I easily applied the new perspective I gained into my work done in other programming languages. The fact that I don’t write that much code in Golang is irrelevant because the knowledge from learning it alone was valuable.

Programming languages are still software and we can build any software in any language. That means that the differences between languages lie mostly in personal preference with a few exceptions. Different languages make some things easier and some things harder. They all have their own trade offs.
What I think does matter is capitalizing on the different paradigms. There’s little perspective gained from learning C# if you already know Java. The languages are so similar except for a few pedantics points. And while PHP and Python have many apparent differences, folks tend to use the same patterns when writing code in both.
Languages that are wildly different from the ones you know are a treasure trove of knowledge though. Every new concept they introduce to you is another tool in your developer’s tool belt. Like all tools, they won’t be applicable for every problem. But having more tools will give you more options for any problem.

Learning Golang definitely added a few new tools to my tool belt. The perspective I gained from that language was an invaluable addition to all my experience in Java/PHP. It was certainly more useful to me than learning C# (which I did like though).

The next languages on my list are Haskell and Erlang. I’ve heard fantastic things about them and I look forward to seeing the paradigms used by them. Even if I never use those languages in the software I build everyday, the concepts those languages introduce to me will make me a better developer overall.

Sunday, January 08, 2017

Software Developers Should Have Sysadmin Experience

Being​ ​a​ ​software​ ​developer​ ​and​ ​being​ ​a​ ​system​ ​administrator​ ​are​ ​very​ ​different​ ​things.​ ​Many folks​ ​lump​ ​the​ ​two​ ​professions​ ​together,​ ​but​ ​the​ ​skillsets​ ​do​ ​not​ ​overlap​ ​much.​ ​Software developers​ ​write​ ​code.​ ​System​ ​administrators​ ​maintain​ ​the​ ​computer​ ​systems​ ​that​ ​the​ ​code runs​ ​on.
Both​ ​are​ ​critical.​ ​Software​ ​provides​ ​value​ ​to​ ​users​ ​such​ ​as​ ​yourself,​ ​but​ ​software​ ​can’t​ ​exist without​ ​an environment​ ​to​ ​run​ ​on.

Many companies like to keep developers and sysadmins on separate teams. This makes sense in theory. You have two different skillsets for two different professions. Why not have two different teams?

The biggest issue with this is that context is really important when building software. Software developers need to understand the environment where their code will be running or they may not build it properly. An analogy: imagine you were tasked with building a house without knowing where it was. You’d probably design a decent enough house.
But then someone takes that design and builds it... on an incline.

If a software developer has never done any sysadmin work, then they will build code that works in theory. The developer tends to build software on their single computer. Most software on the internet runs on multiple computers. The bigger sites like Google or Facebook have thousands and thousands of computers. But like our theoretical house that worked on flat land, code that works in theory can completely fall apart when it becomes live in front of users. This can come in the form of bugs or the software crashing.

For example, think of a website where you upload images such as Facebook or Twitter. Facebook and Twitter have way too many people using them to have those services run on a single server/computer. So they have multiple web servers set up to deliver their website to you.
Why does this matter? Remember that developers tend to write code on a single computer. They could write code that stores the image on the same hard drive as the web server, which for them is the same. Yet problems arise when that code goes live in front of users like you.

If there are 3 web servers and the image is stored on the hard drive for one, then 2 out of 3 people will be unable to see it. If you had 300 friends, then only 100 people would be able to see the image you uploaded. What a terrible service!
The proper way to fix this is to use a distributed file system that is accessible by all web servers.
A developer with little experience will not realize this though. They write code on a single computer. The image will show up 100% of the time when they test their code on their one computer. It is only after the code is being used by users on live web servers does the problem occur.

There are dozens if not hundreds of other examples. Someone needs to explain to the developer how these things work, but being told something is not nearly as effective as experiencing it for yourself. Experiences create a deeper understanding.

That understanding will help catch errors much earlier in the process. A developer with no sysadmin experience will go through a flow where:
  1. They write code
  2. They send it over the wall for code review and/or testing
  3. The code is sent back to them to be fixed.
This can be a time consuming process normally.

Things can also get worse because often times sysadmins won’t look at a developer’s code. That means that users could see bugs first! These kind of issues are also hard to investigate because it will work perfectly on a developer’s computer. They won't be able to recreate the issue easily.

Admittedly, I hate doing sysadmin work. I know there are people who enjoy it, but to me it is just a constant source of frustration. It’s a separate skillset from writing code, but it stands in my way to get people to use the software that I built.

But I do it anyway. I do it because the context helps me write better code. I do it because code that works on my computer is useless. The code that matters is the code that works on web servers that are live in front of everyone else. Just writing code is only doing half of the job a software developer needs to do.

Sunday, January 01, 2017

Follow Up On "What Makes A Senior Software Developer"

A few readers asked me to do a follow up with the responses people sent in for what they thought made a developer a senior developer. I compiled all the emails I received with the comments on Hacker News.
Many folks had their own version of the checklist with different items on their respective lists. I found one to be very interesting though. I was sent a link to a post on this exact topic by Frontside.

At first glance it just seemed like a more complicated checklist. Yet there is one key differentiation: they accept that a senior developer does not need to complete every item on their tracks. There are options a developer can take that best fit their own preferences for how they want to grow in their career.

I’m a little skeptical of the approach because of how complex it seems at first. My worry is that a developer could spend an inordinate of time trying to understand the triangles. As with the checklist, they could spend more time focused on the attributes in each triangle instead of focusing on the work in front of them.

Still, the idea is different enough from a regular checklist that I’m really intrigued. If anyone else has tried it, I would love to hear how it went!

Another interesting concept suggested was that software developers should be licensed. The idea is it is impossible to have a consistent standard for what makes a senior developer without having a… standard for the profession.

It makes sense and it is an idea worth discussing. A lot of caution needs to be taken with this approach though. Who gets to decide what goes into the standard? A vote among all software developers? Who gets considered to be a software developer? Should it be a body of experts? How do you define who an expert actually is?

More importantly, any standard would need to account for the fact that there are very many different kinds of software developers. Working for NASA is going to be very different from working on a mobile tower defense game. Working on a social network will be very different than building software for medical devices. Working for a startup with no customers will be different than working for a company with thousands of customers. Technical debt is less of a concern if you don’t have product-market fit.

Professional licenses is a fun thing to discuss, but a great deal of caution needs to be made if it ever gets put into practice.

Many interpreted my post to advocate for developers who work independently and don’t need to ask for help. I actually disagree with this. A senior developer should be capable of doing work independently, but software development is a team effort. They should know when they should ask for help, but be able to function without it if necessary.

People sent me two great ideas that go hand in hand with this:
  • Senior developers have encountered lots of different problems 
  • Senior developers have the ability to identify gaps in their own knowledge
The number of problems a developer sees helps them create mental abstractions that they can use on similar problems. The more abstractions they have, the more problems they can solve quickly and with a high level of quality. These developers will also have a better sense of how difficult a problem may be and where their own expertise may be lacking. This is when it is best to ask for help.
Asking for help is an admission that you could learn more about something. That is a healthy behavior to have at any level of experience. The best developer I know (hint: it isn’t me) is constantly asking others for advice. Software development is a large field and it is impossible for everyone to learn everything. There will always be something that a developer will need help with.

One great quote on Hacker News in response to this: Once problems are complex enough there isn't much that can be done as a solo ninja.

The last and most important response I received was the need to actually have quantifiable metrics. They didn’t appreciate my quick dismissal of the idea. Just because judging a programmer by the lines of code they write is ridiculous does not mean all quantifiable metrics are ridiculous.

This topic deserves a blog post on its own. For now I can sum up my opposition to the idea with the following statement: Once you tie quantifiable metrics to raises and promotions, you remove the incentive for a developer to maximize value for the business. You replace it with the incentive to meet your metrics. I have not met or heard of anyone who has actually had success creating metrics that correlate to maximizing business value.

UPDATE 2017-01-22: You can read the post on quantitative metrics here.

Sunday, December 25, 2016

Follow Up On "Beware of Developers Who Do Negative Work"

The post on “Beware of Developers Who Do Negative Work” was both enjoyed by many and highly criticized by many. I’m usually fine with criticism, but one point really stung.
A lot of the criticism denounced the idea that junior developers do negative work. They need mentoring and coaching, not to be frightened and have their insecurities targeted by callous bloggers such as myself.

The point stung for two reasons. The first is that it’s true. You should hire a junior developer with the proper expectation that they do need a lot of mentoring. They will also grow far more in their first 2 years than most other developers will in that same time frame. And it is a shame that while they become 5x to 10x more productive after those first two years, most will have to switch jobs in order to get more than a 10% raise.

More importantly, we all start out as junior developers. If you have no experience, then you are a junior developer. Title is irrelevant. By that definition, all developers start there and all developers need an opportunity to get that experience.

One of my most rewarding experiences was fighting to get one of my interns an offer for a full time position. He obviously made many mistakes during his internship, but he also did great work. My boss thought I was crazy when I gave him an ambitious first assignment. Yet, he nailed it because we worked through the problem together and he understood what he needed to do. He earned the offer we gave him. I couldn’t have been more proud.

The second reason that point stung: No where in the post about negative contributing developers did I mention junior developers.

No where.

In my experience, being junior does not correlate at all with making a negative contribution as a developer. Things that do correlate are:
  • Wanting to appear to do a great job rather than actually doing a great job
  • Trying to do as little work as possible without getting fired
  • Focusing only on your own work and valuing your own time rather than thinking about the team as a whole
  • Living in the comfort of what you know and “how things have always been done” rather than learning something new
To clarify that last point: I mentioned "outdated" practices in the last post. That doesn't mean anyone who refuses to jump on the shiniest new thing is stuck in the past. I personally prefer technology that has been vetted by people I trust. But there are still developers out there who do not believe in source control.

Source control. A standard for at least 2 decades.

There are developers who believe everything needs to be built in house. In a world where we are flooded with great open source projects.

There are developers who still don’t understand why it’s important to decouple front end and back end code. Another common practice for decades.

This is not an attitude that light coaching can solve all the time. This is something that can take months of debate. In the case of overly influential developers, this can be months where the rest of your team suffers.

If you have never worked with these types of developers and don’t believe a word I am saying - that is awesome! We should all work towards a world where all developers have that same great experience.

For now, many of us have to deal with messy situations.

We join companies where a bad developer is favored by the CTO for some reason, or worse… is the CTO.

We join companies that revere a “hero” developer who has always done the seemingly impossible… by writing horrible code that no one else can work with. To non-technical managers, no one else looks like they know what they’re doing except for that “hero”.

We join companies with years of legacy code. Business needs often prevent an entire development team to just take off a year and rebuild everything to work with continuous deployment.

Software development is an extremely rewarding field to be in, but it also has some significant challenges. It can lead us to some dark places. Talking about the negative aspects in our field helps us cope. One developer I worked with said that it even raises morale.

If you think about it, that makes sense. Imagine these corporate situations that happen all too often:

Employee: “The company just reported disastrous earnings last quarter! Will our jobs be safe?”
Corporate representative: “The company is stronger than ever.”
Employee: “You just announced huge layoffs!”
Corporate representative: “We have improved our business synergies and efficiencies.”
Employee: “Our benefits just got cut!”
Corporate representative: “Your benefits have been changed and tailored to best serve you.”
Employee: “What just happened to our equity?”
Corporate representative: “We have entered into a partnership that will make our business stronger than ever.”
Employee: “But what about the equity we received?”
Corporate representative: “You are working for a great company with a great mission!”

Not every company is like this, but many are. They act like this in an attempt to keep morale high. Yet the positive tone is obviously fake. All it does is tell people that they can’t say anything negative. They can’t talk about the things that concern them. They can’t commiserate with their coworkers.

More importantly, we can’t fix things if we can’t talk about them.

Software development is hard, but we can work towards making it better.

To all those who liked the post, and especially those who emailed me their stories: I hope you can use it to make your own development life a little better. Maybe you now have the inspiration to have productive discussions with your managers about the topic. Or maybe you just found the post therapeutic to know you aren’t the only one who has to deal with those struggles. I’d be happy either way. I will continue to discuss all aspects of software development with anyone who will listen and I hope you will too. Sharing our experiences will help us all find the best path forward.

To the junior developers who found the last post terrifying: I’m sorry. I have forgotten what it’s like to just start out. I forgot what it felt like to worry about being fired after every bug during my first few years as a developer. I did not see how that post could have been misinterpreted, but now I do. I can be more cognizant of that in the future. And you should know that junior developers are not excluded from being considered great developers. All it takes is the desire to be better tomorrow than you are today.

Sunday, December 18, 2016

Beware of Developers Who Do Negative Work

UPDATE 2016-12-25: This post has an important follow-up.

At some point in every software developer’s career, we work with someone who does negative work. The notion of negative work may sound a little strange. Someone can do no work by just… not working. How does negative work happen?
One example of this is an awful developer that was once at the same company as me. He made 2 changes to the code base over his 6-month tenure there. These changes just flat out did not work and broke other features in the product. His third code change was to undo the previous changes he had made.

Sounds like he just did zero work. Except that multiple people also encountered his errors. They had to track down whether the bugs they were seeing were the result of their work or someone else’s. They had to discuss fixing the issue with him. They had to help determine that none of the code changes were worth fixing and that the team was better off deleting those changes.

The end result was a few dozen hours wasted across the entire team. This developer did zero work AND reduced the productivity of others.
There are many other examples of this.

I’ve encountered many developers who can write code that works… but it ends up being so convoluted that other developers had to spend a significant amount of time trying to understand it. Granted, trying to understand code that someone else wrote is always a little time consuming. But the degree of how difficult something is to understand matters.

Here’s some quick math to help visualize how this can work:

Bad Developer spends 5 hours writing convoluted code. Other 4 developers on the team each spend 10 hours each trying to figure out how it works.

Net loss: (4 * 10) + 5 = 40 + 5 = 45 hours spent

Good Developer spends 10 hours writing easier to understand code. Other 4 developers on the team spend 1 hour each trying to figure out how it works.

Net loss: (4 * 1) + 10 = 4 + 10 = 14 hours spent

Difference: 45 - 14 = 31 hours

These numbers also rise exponentially. I’ve seen code so bad that it took a good developer 2 weeks to complete a task that objectively should have been 2 hours if the code was written better. The 2 hours is also being generous. That task could have taken 30 minutes if good software design was used originally.

An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company. These developers hate learning new things and having their workflow be different. They abuse their influence to keep processes at their companies the same so that they don’t have to learn new things. As a consequence, other developers on the team are negatively affected.

I once worked at a company where we were investigating a new way to integrate the work different developers had completed. The method we were using was taking us hours every time we needed to do it. At the time we did this twice a week. We were convinced the new method would have brought it down to minutes. However, one influential developer didn’t like any kind of change and they were allowed to veto any forward progress. It took 6 months to finally go through with it at which point that developer had to be largely ignored.

4 hours * 2 times a week * 26 weeks = 208 hours wasted over 6 months

Ouch. That is 5 weeks worth of working hours for a single person.

Can you imagine if you just did nothing for 5 weeks? If those weeks were just a waste of your life?

Fortunately those 208 hours were distributed among more than a dozen people, but it is still a terrible situation. This was also only one example at that company. The attitude that prevented progress in this one area also prevented progress in many other areas. A lot more time was wasted in other out of date practices.

That leads into the human cost of developers who do negative work. Most people want to feel a sense of accomplishment when going to work. They want to feel like their time was spent on something worthwhile. For developers that means delivering software that brings value. Wasted time prevents that.

Most of us also want to work with talented people. Working with someone who is a burden on the team is an emotional drain. They act as an obstacle to our success. They can also make us feel less value in the work we do.

The job market for developers makes it very easy for developers to solve this problem: finding another job. This is obviously an undesired outcome for a company.

So if the cost of a developer who does negative work is so high, how do they get hired? Part of it can be explained by an interview process that needs improvement, but a less talked about part is the temptation to lower hiring standards.

Sometimes a company is in a situation where a lot of work needs to be done very quickly. If there are not enough developers in the company to accomplish that goal, then more developers need to be hired. Since developers have the advantage in the job market today, it can take quite a bit of time to make a good hire. That is when the temptation to lower hiring standards appears. When the amount of work is overwhelming, some people hire in a panic. They think having more bodies in the office can only contribute to more work getting done.

That is far from the truth. Not all developers will bring positive value to your team. I understand the pressure of tight timelines, but hiring in desperation won’t solve that problem. It’ll make it worse. Bad developers will not only slow you down, but they can cause your great developers to leave your company. You will be even further behind on your project than if you hadn’t hired anyone.

I would love to hear from you if you have experiences with bad developers that you would like to share!

UPDATE 2016-12-25: This post has an important follow-up.

Sunday, December 11, 2016

What Makes A Senior Software Developer?

UPDATE 2017-01-01: This post has a follow up.

Most engineering organizations will have to answer the question: “What makes a software developer a senior developer?” This is a challenging question because it is extremely subjective. Search for the answer on the internet and you will get many different answers. Some will contain criteria that are also subjective themselves which adds additional difficulty to the question.
What makes the question even harder to answer is that some companies don’t really care. The senior title is extremely easy to hand out because it does not require a change in the reporting structure for the organization. That makes it useful to hand out when recruiting.

“Oh this other company is offering you 20% more money? Well, we will give you a senior title instead!

On that same line, a company may also be able to get away with giving smaller raises if they hand out the title.

“We can’t afford to give you as much, but you’re seeing rapid career growth!

This is in contrast with companies that do care and have a high bar for developers with the senior title. These companies want to make the title meaningful. It should go to great developers in recognition for the value they bring.

While that is a worthy goal, it still leaves us with the challenge of figuring out how to answer the question of what makes a senior software developer.

There is the “This person is doing a great job! Time for a promotion” approach. It’s easy to do because it’s simple. You follow your gut. The problem is that this approach can be prone to favoritism.

“This person is fun to hang out with! Their work is also really awesome. Time for a promotion.”

Even if there is no favoritism, this approach can lead to the appearance of favoritism. There could be someone else who thinks they are just as good as the developer who gets a promotion. If you’re unlucky, they will let their feelings swell up and eventually quit. If you are lucky, they will come and talk to you about why they didn’t get the promotion. At that point you have to have a better answer than “Oh you’re just not good enough yet.”

This leads us to the polar opposite of the follow your gut approach: creating a checklist.
Having a checklist of criteria can make it seem very easy to answer why one person got a promotion, but another did not. It also provides a map for someone who wants the promotion to get there.

There are many problems with the checklist though. The first is: if you were tasked with building a checklist, would you stop at 2-3 items?

Probably not. When we start building a checklist, we feel the need to fill it with things. Even if 2-3 items was appropriate, a short checklist is a sad looking checklist. If we get stuck at 2-3 items, we will start trying to find things to put down for the sake of putting them down and making our checklist look fuller.

This can lead to misplaced incentives. For example, let’s say you have “mentoring” on your checklist for a senior developer. We all know that being an expert in something does not mean that the expert has the ability to teach that topic effectively. What if your developer was phenomenal in everything else on your checklist EXCEPT mentoring? Would you stop their career progression for one item? Would you make them take time out from improving their other skillsets so that they can check off one thing on your list? That may not be the best way to bring value to a company, especially if you already have great mentors in your organization.

The other problem with checklists is that they only work well if you have quantifiable metrics for being a senior developer. There are no good quantifiable measures for being a good developer though. Lines of code written doesn’t work. Number of bugs fixed doesn’t work. Number of hours worked definitely doesn’t work. Every measure of a good developer is qualitative. That makes them all subjective. That makes the checklist no better than following your gut. In fact it’s actually worse because the checklist creates overhead in people spending their time building it and trying to follow it. Neither will bring value to a company.

I once had the pleasure of arguing for the promotion of a developer on my team. The reason I did this was because I noticed one day that for some reason I was much less stressed at work. That reason was because I had a much lighter workload. I didn’t need to scrutinize code reviews as much as I once did. I didn’t need to approve as many decisions as I once did. I didn’t need to handle as many issues resulting from my team’s work as I once did.

I didn’t need to do these things because this developer had improved his abilities significantly. His code quality was much higher. His reviews of *other* developers’ code was much better. Instead of reviewing every pull request, I only needed to review the pull requests that he had not already reviewed. And most importantly, he would move forward with projects if I wasn’t available. Sure he would still confirm things with me when possible, but the lack of my approval would not stop him from making progress.

There was a time where very little would get done if I took a vacation. When that stopped happening is when I knew this developer had become a senior developer, at least in abilities if not yet in title.

To me, what makes a senior developer is when you can trust them to get things done without you.

That criteria is still extremely subjective and very similar to the approach of following your gut. I could argue that it at least gives you a foundation for pointing at examples: “this was a great code review” or “that project was well handled”. Yet, those are still very subjective. You are still left open to the perception of favoritism. I’m not entirely sure there is any way around that.

If you have any thoughts to add on what makes a senior developer, I would love to hear from you!

UPDATE 2017-01-01: This post has a follow up.

Sunday, December 04, 2016

Should You Hire a Bootcamp Graduate?

Developer/coding bootcamps are incredibly popular right now. That should not be a surprise to anyone. Software development is an incredibly lucrative field. There is a much greater demand for talent than there is supply. I’ve seen that from both the hiring side and the job applicant side. It makes sense that a lot of folks out there are interested in becoming software developers. Bootcamps are there to help fill the demand for that education. $20,000 for a bootcamp sounds like a lot, but it is a lot less than $80,000+ for 4 years of college.
Photo courtesy of Dev Bootcamp
The point of contention is: can someone be as qualified after going to a 6 month bootcamp than someone who spends 4 years in college?

Many do not think so. An in-house recruiter I worked with often asked our organization to keep an open mind about bootcamp graduates. This was because other members on the team would rule out applicants solely because they had attended a bootcamp.

Part of that mentality was due to a saturation of candidates. Many bootcamps, though not all, are “dev mills” . Their goal is to get people in and out of the bootcamp. The bootcamp earns tuition regardless of whether the students get jobs after graduating or not. Many bootcamps also make unreasonable promises. “Come to our bootcamp and make $100K+ after 6 months!” They sell the dream and make it sound like it will be easy.
Photo from the Great Depression
The result is a large number of people who assume they can go to the bootcamp, complete just the coursework, and then be ready for a job. Unfortunately, just doing coursework doesn’t cut it. The result is hiring teams are overwhelmed with the quantity of unqualified candidates.

The catch? My point on coursework applies to 4 year degrees as well. There are also plenty of 4 year college graduates who are also unprepared for professional work upon graduation.

Software development is a great field to be in for many reasons, but it is also hard. I won’t go so far to say that you HAVE to love the work. Yet, you DO have to be interested. The field changes often. Developers need to constantly learn and get better at their craft, or they will be quickly left behind by their peers. The education a developer gets, regardless of the source of education, can never teach everything they will need to know. Education serves as a foundation for additional learning. That additional learning is what makes candidates qualified for a developer job.

Filtering job applicants by bootcamp graduate or college graduate reminds me of companies who filter job applicants by GPA. There are plenty who only hire those with 3.5 GPAs or 3.0 GPAs. I found this to be a useless metric. I once interviewed a slew of candidates from the same university. What I found interesting was that many of the candidates with great GPAs could only give me textbook answers to my questions. I would ask “how have you designed some of your software projects?” The responses I got were textbook definitions of software design patterns. If you had told me before that experience that multiple people would just recite definitions from textbooks, I would not have believed you. Imagine my surprise after that day.

Many of the students who were barely passing their classes gave me fantastic answers to that same question. They would talk about their projects, what they think went well, what mistakes they think they made, and what they would do different in the future. Instead of reciting what the factory design pattern was, they could give me an example of how they used it and why they chose it. Those are the kind of developers I want to work with.

That experience alone made me think differently about bootcamp graduates than some of my peers. If the GPA filter is useless, why is the bootcamp filter any different?

I have interviewed some really phenomenal candidates that had gone to bootcamps. One in particular told me that she chose not to use a framework for her first few projects even though her instructors told her to. She wanted to see what difficulties she would encounter without that framework. Only then would she truly understand the value that the framework would give her. She chose to gain a deeper understanding of the technology used in software development rather than blindly do what she was told.

That is the mentality required to be a great software developer. Whether a person has that mentality does not correlate with going to a bootcamp or going to college. The coursework alone will never prepare someone for a job regardless of how comprehensive it is. Once again, the goal of education should be to serve as a foundation for more learning later on. The will to seek out additional knowledge depends on the individual, not their source of education.

In the end, the answer to the question “Should You Hire a Bootcamp Graduate?” is yes. Because it doesn’t matter if someone graduated a bootcamp or not. We should evaluate all candidates on the same factors that determine whether a person is a good developer. Can they write good code? Do they understand the fundamentals of software development? Do they continue to learn new things over time? Those are the questions that matter. Who the individual person is matters. The question of where someone received their education is worthless.

Sunday, November 27, 2016

Code Reviews Are Awesome... Sometimes

Code reviews are seen as an essential part of software development. It makes a lot of sense to say that a programmer should have their work reviewed by another programmer. Authors and journalists have their work reviewed by an editor after all. Humans make mistakes and creators especially get a little tunnel vision when they are focused on making their creations. Having someone else look at it can catch many errors.
In software development, code reviews also have the added benefit of reducing your reliance on a single person. With code reviews, multiple people have looked at a piece of code. If the original author disappears for any reason (gets sick, quits the company, is hit by a truck, etc), someone else is familiar with that code in case any issues arise.

The theory behind code reviews is sound. The problem is what happens in reality. Reading software code is not like reading a novel. Whereas novels are linear:
software is a branching system:
If the amount of code being reviewed is small, then it is more likely to be linear and easier to review:
Unfortunately that often applies to bug fixes or small tweaks to features. Major features are rather large. A developer I know told me that he and his teammate would often do week long code reviews. Not great for the developer waiting on a review and not great for the developer doing the review. Definitely not great for the company that needs software delivered to users.

Another major problem with code reviews of this size is that a review of code is happening after days or weeks of development have gone into it. What happens if the code is fundamentally broken and needs to be rewritten from scratch?
One possibility is that the code review discussion results in rewriting the code. This is highly unfortunate because a lot of time was wasted on writing the original code. Losing days or weeks of a developer’s time with little to show for it is not a recipe for a successful business. I personally have not seen this happen very often though. What does happen is much worse.

The reviewer realizes the code is fundamentally flawed and approves it anyway.
This happens when a deadline is approaching and the team can not afford to rewrite days or weeks worth of code. So they accept the broken code and any issues that may happen down the line such as bugs or the website going down when a lot of people go to the site. The project is delivered “on time”, but with obvious adverse effects. More time is spent cleaning it up in the following months than would have been spent rewriting it.

The common response to these problems is that all code reviews should be broken up into small chunks which make it easy to review. It makes sense because the smaller the amount of code being reviewed, the more linear it becomes. However, that argument ignores the value of context. Imagine someone creating a very well written introduction to Quantum Physics. You may read it and go “Yep, that’s a well written introduction! I feel like I understand the general idea of what Quantum Physics is.” Yet it would be completely inappropriate if that well written introduction was put in the middle of… a romance novel (unless you have a very niche demographic for that romance novel).
An alternative to code reviews is design reviews. This is a high level discussion of how an entire system is supposed to work before any code is written. It is way easier to have a discussion around a diagram:
Than it is to have a discussion around code:
I love design reviews because you catch problems early and you have more meaningful and important conversations around the code being written. Going back to the novel analogy: it is more important to discuss the high level ideas such as general setting, character development, major plot twists, etc, than it is to make sure that individual words and sentences are perfect. Being grammatically correct with correctly spelled words will not help if the novel as a whole makes no sense. The same is true of software.

The problem with design reviews though is that they can be overkill. They make sense when you have to build something from scratch. They make less sense with most software bugs. With bugs, you don’t necessarily know where the problem is or how to fix it right away. It is a lot of investigation with a lot of trial and error. By the time the root cause is discovered, the programmer may already have a fix for the bug. This is when code reviews make sense. Why do a design review when the code is already written? Do you review the setting of a novel after fixing a single typo? Probably not.

Code reviews and design reviews are like any other tool in a programmer’s toolbelt. Sometimes one is appropriate and sometimes the other. It should be up to the team to decide which they need to use in a given situation. The idea that every team should always do one or both for every piece of code that is written is the equivalent of having a hammer and seeing nothing but nails.

If you enjoyed this post, you may also enjoy: Balancing The Desire To Under-Engineer and Over-Engineer

Saturday, November 19, 2016

Programming Has Changed My Life

Sometimes I look back on my life and wonder what it would have been like if I had never started programming. Obviously my career would be different, but I believe that programming has fundamentally changed how I think. Who I am as a person has changed significantly due to solving as many software problems as I have and the changes have been for the better.
Teenage me was severely flawed. That guy formed opinions very quickly with little evidence or thought put into it. That alone wouldn’t be so bad if he also didn’t hate being wrong. He hated being wrong so much that he would stick to his poorly formed opinions regardless of how well the arguments against him were. And no opinion was greater than the one that nothing was ever his fault. There was always someone else to blame for anything that went wrong. I’m surprised I still have friends from back when I was that guy.
Going to college was like hitting a brick wall. It is extremely difficult for a person with the above character flaws to make it through a year of computer science classes. The reason is due to the nature of writing code. Despite all advances in AI, computers are pretty dumb. They do *exactly* what you tell them to do. No more. No less. But you can’t just tell them to do things like you would ask another human being to do something. Computers have their own language: code.

Talking to a computer is not like talking to a human. Computers have no opinion. They don’t care about being right or being wrong. They just do what they’re told. That means that you can NOT simply be stubborn and win an argument with a computer through sheer force of will. Computers don’t care that you yell at them.
If you wrote code that doesn’t work, there is only one way to get that code to work: figure out what you did wrong.

That was an important paradigm shift from what I was doing in my life. My primary activity, programming, required me to constantly think about what *I* was doing wrong. Stubbornness only resulted in me sitting in my chair, fuming, yelling at a computer that didn’t care that I was yelling at it, and making no progress. I needed to stop being angry and start thinking about what I was doing wrong if I wanted to get programming assignments done in time. Often that required using a different approach than my initial one. There goes my tendency to stick with poorly thought out initial opinions!
This kind of personal growth did not end after college. If anything it accelerated when I started working professionally. I once spent several days working on a single piece of code. An initial opinion was formed and I started writing the code. I invested several days of my heart and soul there. I struggled with an endless stream of things going wrong and plugging holes every time one popped up. I was sure that my initial approach was the right one and each hole I fixed would be the last one. There never was a last one.

By the end I was prepared to deliver a broken product to my boss and say “this is the best I can do”. I was frustrated and couldn’t take it anymore. Then I realized my entire approach was wrong. I threw out all the work I had spent so much time in and re-wrote everything in two hours.

Two hours.

That is all it took to do what I needed to do. It was a harsh reminder that initial opinions are nearly worthless and that stubbornness only results in wasted time.
There have been many other harsh reminders over the years. Software development is a rapidly changing field. Accepted practices change and new technology is constantly being developed. Some developers choose to stick with what they know and only what they know. They are finding out that in software development, you learn or you become obsolete. End of story. Even if they can convince non-technical managers running a company that their old ways are the best way, that will only lead to a sub-optimal development team. Companies who accept this become extremely vulnerable to competitors who don’t.

The lessons I learned from programming did not stay exclusive to my career as a software developer. They carried over into all other aspects of my life. I’m a much less angry and much more tolerable person to be around for those close to me. I also think more pragmatically when making decisions, whether it is figuring out how much to save for retirement or eating healthier. Most importantly, I have accepted that some things are just hard. Some problems have no easy answers. Often times the only solution is to hunker down and do the work to figure things out.
There’s no telling if I would have learned these lessons some other way. It doesn’t matter though. In the life I lived, programming has taught me these lessons. Programming has changed my life for the better.

If you enjoyed this post, you may also enjoy: Teach Writing Code First
If you are interested in learning to code: try my lessons!