The most awesome story I read yesterday was trial coverage from Oracle’s lawsuit against Google over Java and Google’s reimplementation of Java for Android. Here’s the judge explaining to Oracle’s attorney (famed litigator David Boies) why Google had no incentive to copy the code they were alleged to have copied:
I have done, and still do, a significant amount of programming in other languages. I’ve written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There’s no way you could say that was speeding them along to the marketplace. You’re one of the best lawyers in America, how could you even make that kind of argument?
As folks like Ray Cromwell and Mike Loukides point out, this is the best refutation I’ve seen for the argument that people shouldn’t learn to code.
As a software developer, I’m thrilled that Judge William Alsup learned to code at some point, and that he’s doing some programming to help evaluate the evidence being presented in court. It’s common to see people making policy decisions, legal decisions, and business decisions that wind up being terrible because the decision makers lack the technical knowledge to even solicit good advice.
As I said yesterday, I welcome anyone who wants to dive into programming.
Jeff Atwood wrote a provocative blog post entitled Please Don’t Learn to Code that I wasn’t going to respond to because it looked a lot like trolling to me. What I think, though, is that Jeff is conflating the suggestion that people learn to program with the suggestion that everyone should be a software developer. In the end, though, the post is just a mess.
I’m not for falsely equating programming with essential life skills like reading, writing, and math, or with the things Jeff suggests people spend time on instead — learning how things work at a “basic level” or becoming better communicators. That said, I would encourage people to learn to program for a number of reasons.
The first is that much of the world is run by computers. Learning to program involves learning how computers work at a more basic level. Even just knowing how the Web works at a technical level is helpful, if only to know if something is broken on a site you’re using or on your local computer.
In some ways, the relevant analogy is to auto repair. Knowing how your car works and how to fix some things doesn’t make you a mechanic, but it does make it less likely that you’ll be stuck on the side of the road with no recourse other than roadside service, and also helps to ensure that you won’t be exploited when you have to deal with a mechanic.
There are many people out there who work with software developers who are not themselves software developers. Understanding how to program makes it easier to communicate with them.
The second thing is that learning a little programming can make you better at your job if your work involves using a computer at all. Here’s my favorite programming story of all time. I used to work with a software developer who started her career at a chicken processing plant in Arkansas. She started not as a programmer but as an administrative assistant. Back then, they didn’t do word processing, they typed on typewriters.
Even though she had no formal training as a programmer, she figured out that the electric typewriters they used were programmable, and learned how to program them to complete various forms rather than typing them in by hand. Her boss noticed her good work and had her learn how to program another computer they had in the office. Eventually, he encouraged her to quit and go back to school to become a professional software developer.
Had she not been a smart and curious person who figured out that programming would make her job easier, she may still be working in that chicken plant. Today programming is now a more fundamental tool of automation than it has ever been. How many people could eliminate redundant work if they knew how to write scripts to collect data for them and schedule them to run nightly? How many people struggle with terrible Web applications that could be improved with user-created style sheets or Greasemonkey scripts? Programming empowers you to remove annoyances from your daily life.
The third reason is that learning to program teaches you a different method of problem solving than most people are familiar with. Learning to program teaches you how to break down problems into familiar components and then meld those components together to create a solution. Programming is not the only way to learn those skills, but it’s a good way to learn them, and that skill is widely applicable to every day life.
I wouldn’t make the argument that we make programming courses mandatory in school, or that everyone should learn to program, but I would encourage anyone who has the slightest interest in programming to pursue that interest.
There’s a lesson for software developers in this paragraph:
I did all my email work in that one “legacy” tab, marveling at how much I preferred it to the new-look Gmail that was the only option in any newly opened tab. I carefully “slept” the machine at night rather than shutting it down. I cancelled any software update that required a system reboot. I worried about what would happen if I unthinkingly closed the tab. It was my living connection to happier days.
That’s James Fallows, explaining how he attempted to keep using Gmail through the old interface.
For a long time, I was shocked by blogs like Etsy’s engineering blog, Code as Craft. I had a sort of old-school “information is power” mentality that led me to believe that letting competitors know about your technology stack would put a company at a disadvantage. Building scalable systems is hard, and I thought it was foolish to give away your secrets. I also prided myself on being able to sleuth the details of a company’s technology stack using URLs, HTTP headers, and page source.
I have long since come around to the opposite point of view, but general attitudes about this stuff hasn’t changed much once you get past the most progressive organizations. Stephen O’Grady explains to the recalcitrant why hiding your technology stack is a bad idea.
The other day I said on Twitter that all problems are user experience problems, except for scaling. And the solutions to those problems are generally so complex and so specific to a company’s product, staff, customers, and existing code base that slavishly copying one’s competitors at meaningful levels isn’t really possible. At most, what you usually get is an idea of what to try next, or issues you may run into down the road.
The advantages of sharing are real, and the disadvantages are an illusion. Go forth and start an engineering blog.
Here’s a fantastic post from Rebecca Murphey that lists the skill set front-end developers should be working to attain. Here’s her prediction of where things are headed:
Whatever it is, I think we’re seeing the emphasis shift from valuing trivia to valuing tools. There’s a new set of baseline skills required in order to be successful as a front-end developer, and developers who don’t meet this baseline are going to start feeling more and more left behind as those who are sharing their knowledge start to assume that certain things go without saying.
I’m primarily a back-end developer and her list works for me as a way to get up to speed on what’s happening on the cutting edge of front-end development these days. It’s great to see a lot of the techniques and tools that we’ve been using on the back end for years starting to benefit front-end developers as well. It’s no longer the benighted wasteland that I once perceived it to be.
Lately, I’ve been interviewing a lot of developers. Not phone screens, but in house interviews that we use to decide whether to hire someone who’s passed the first round. In addition to trying to figure out who the good candidates are, I’m also trying to get better at interviewing.
If you’re getting started with interviewing programmers, there are a couple of must-read articles. The first is Steve Yegge’s article, The Five Essential Phone-Screen Questions. This article is incredibly well-known and I assume everyone has already read it.
The second is Joel Spolsky’s The Guerrilla Guide to Interviewing. He recommends asking an “impossible” question (as anyone who worked at Microsoft probably must). I never ask these kinds of questions. Other than that, I think he’s got it right. You want to know if they can code, if they can design something, and how well they think.
One thing that stands out to me, though, is that none of his questions tell you what kind of team member the candidate will be. This is a major deficiency as far as I’m concerned.
Basically, at the end of an interview, the one question I want answered is, “Will it suck to work with this person?” As Joel points out, it’s important to hire smart people who get things done. It’s also important to hire people who won’t make the people around them miserable. I want to hire people who are flexible enough to adapt to the company culture and open-minded enough to recognize other people’s good ideas. I also want people who are patient enough to bring other people up to speed on their work.
There are a few questions that I’ve settled into asking almost everyone. I don’t worry about people finding me on Google and knowing in advance that I’ll ask these questions because I’d just as soon they come in already knowing the answers.
I almost always lead off with, “Tell me your timeline of programming languages.” I want to know how long they’ve been programming and how many languages and platforms they’ve used in their career. All things considered, I generally prefer programmers who’ve worked extensively with multiple languages. This question is also an easy way to find out which people started programming early in life.
Next, I usually ask them about some experience from their résumé, I’ll pick a project and drill down to find out what the project was, what role they played, and how well they can explain what they worked on.
I then ask them some questions about teamwork. I’ll ask them to tell me something they learned from another developer. Many people talk not about technical concepts but about habits of work, and either sort of answer is fine. If they can’t tell me something that they’ve learned from someone else, that’s a big red flag.
I ask them to tell me something that they’ve changed their mind about when it comes to software development. If you can’t remember changing your mind about anything, you may be too stubborn to work well on a team. It turns out that lots of people have changed their mind about the ternary operator. It’s polarizing.
I will generally ask candidates how they test their own code, to find out what kinds of automated testing they use (or don’t use).
The last question I have started asking almost everyone is to tell me something that they would rewrite if they were given time. It’s a good way to get someone to talk about something they feel strongly about and also to find out what they see as good and bad code. It’s also telling if they want to rewrite something someone else wrote rather than something they wrote.
I’ll also ask a few questions about why they’re looking for a job and what interested them about the company just to get a sense of how interested they are in the position. And of course I ask them if they have any questions for me.
There are three other areas that I think are important to hit, and this is the area where I’m still working on my technique. Those are coding, design, and problem solving. The trick is to fit all of it into the short window that I usually have for the interview. At worst, if multiple people are interviewing the candidate, you should make sure that at least one person will be hitting each of these three areas.
The ideal programming question as far as I’m concerned should be simple enough to solve in a couple of minutes, and be deep enough to have multiple solutions. The best questions have at least a brute force solution and an elegant solution. You can gauge the candidates on which they come up with. I refuse to ask the famous Fibonacci sequence question. There are better alternatives. That said, if you are interviewing for programming jobs, you should be able to write a program that prints the Fibonacci sequence using a loop or using recursion. Someone will ask you to do so.
Design questions are discussed comprehensively in Steve Yegge’s article, which I linked to previously. The goal is to determine whether the candidate understands object-oriented design. The model should be simple enough that you can get past the classes and get into talking about the methods on those classes.
Finally, I think it’s good to ask a question that tests the candidate’s problem solving skills. They should be able to list possible solutions and discuss the pros and cons of each of them. I’m going to write a separate post about this type of question later.
Google engineer and former Harvard professor Matt Welsh does a great job of making the case for code reviews. I have never worked in a shop where code reviews were mandatory for every change, or even commonly held, but I’ve always wanted to for all of the reasons Matt Welsh explains. There are a lot of excuses for not doing code reviews, but I can’t think of any more efficient way to encourage developers to learn from one another and to develop a cohesive coding style that spans an entire team.
In an email explaining how he optimized GNU Grep for speed, Mike Haertel discloses the secret of high performance software:
The key to making programs fast is to make them do practically nothing.
I liked this, from DHH:
The progress of technology is throwing an ever greater number of optimizations into the “premature evil” bucket never to be seen again.
That can be a tough lesson for those of us who have been developing software for awhile to internalize. It becomes ever more sensible to optimize for simplicity rather than performance.
Today I was talking to a friend about his job. He said his company had just had a meeting where the management told his team that they were not satisfied with the overall sense of urgency and that the team needs to be getting things done more quickly. Reading between the lines, it was clear that what the manager meant was that the team needed to be putting in more hours.
Working more than forty hours a week is hardly outside the norm in software development, but directly demanding more hours from people is a bad idea for a number of reasons. I won’t get into basic issues of justice and decency and instead focus only on effectiveness. Even if your only goal is to get things done as quickly as possible, demanding that your team work more as a group is still a bad idea.
The first issue is morale. Members of the team will not readily accept “work more hours” as a possible solution to any problem if other solutions that don’t require them to work more hours are apparent. If there are process changes that would make the team more productive, they’ll wonder why those aren’t being made instead. If there are underperforming members of the team, others will wonder why those team members aren’t being specifically urged to do a better job or being replaced.
And, of course, some team members will start asking themselves why they’re working at a place where the management tries to solve problems using the blunt instrument of “work more hours.” In the end, you wind up with an unhappy team that starts losing its strongest contributors to other jobs. If you do plan to go this route, understand that the team will hold you accountable for every second of their time you appear to waste, so you’d better have your ducks in a row.
The second issue is quality. This is an issue I touched on when I talked about the problem with all-nighters. When someone is working and they know they could be doing something else, whether it’s having dinner with the family, going to their kid’s soccer practice, or sleeping on the couch, chances are their focus is going to be on doing whatever it takes to finish as quickly as possible. Corners will be cut. The longer the team is working extra hours, the more technical debt you build up, which in turn makes it harder for developers to get things done, requiring even more work to maintain the same level of production. It’s a losing proposition.
The third reason not to fall back on “make them work more hours” as a strategy for increasing productivity is that it reduces the organization’s capacity to manage a crisis. For one thing, there are fewer hours to throw at unexpected problems. If your lead developer is already working on Sundays, those Sundays aren’t available when you get a surprising feature request from a big customer. If the team is already burnt out from previous death marches, they’re going to be pretty cynical when their confronted with an actual crisis. And finally, when the crisis arises, that crappy code people were writing at night when they were trying to watch Glee at the same time is going to be an impediment to solving whatever problem is at hand.
The funny thing is that on a good team, you never need to ask people to work more hours at all. If you have good people and they understand and have bought into the team’s goals, then they will do what needs to be done to ship, even when it means putting in extra hours. One way to make sure that never happens is to coerce them into working more hours.
Every time you’re tempted to do so, sit down with members of the team and ask them how many hours a week they spend dealing with stuff not related to shipping and work to make those things go away instead.
© rc3.org. Powered by WordPress using the DePo Skinny Theme.