A scientist and developer



a person who designs, builds, or maintains engines, machines, or public works.

  • a person qualified in a branch of engineering, especially as a professional: an aeronautical engineer
  • the operator or supervisor of an engine, especially a railroad locomotive or the engine on an aircraft or ship.
  • a skillful contriver or originator of something: the prime engineer of the approach

Recently, while having drinks with a fellow Georgia Tech alum who works in the software industry, I brought up something that I always found a little funny about our current line of work.

Many people who develop software or work in the software industry call themselves “software engineers”. I always found the term a bit off because I have a Bachelor of Science in Computer Science. There’s no mention of “engineer” anywhere on my diploma. My friend’s theory involves some politics and controversy at the fine North Avenue Trade School that led to the designation of software development as the Science school as opposed to the Engineering school, but I’m not sure they got it wrong.

As the definition from Oxford’s dictionary above indicates, an engineer doesn’t describe what those who write software do. I currently prefer the term software developer since much of my time is spent working on more than just systems or maintaining machines. Agile and Lean processes, cross-functional teams, feature development, A/B testing, and platform architecture involve very little of the rote, document-heavy engineering of software’s past or other schools of engineering.

Having gone to school with people whose sole concern was engineering, not to mention my father’s lifelong employment as an industrial engineer, I found this choice of nomenclature somewhat odd and off-putting. I felt like I was pulling wool over people’s eyes when I said I was a software engineer. I’m a scientist. Why doesn’t the term computer scientist used commonly in job titles?

In the past, I worked on the backbone of telecommunications networks and in the waterfall, Gantt chart-filled world of software development before Agile or Lean became popular. These days I don’t reference many white papers published by IBM or Bell Labs or books that fill the engineering world like Engineering Documentation Control Handbook. I’m more concerned with languages, patterns, design, and developing applications for consumer technology.

So I say to you, developers of software, embrace the identity of a scientist or developer, not of an engineer.

The interview: trying to be objective

I’ve been thinking quite a bit about how companies interview and find talent.

Hiring the right people is important

For many companies, this can really make or break the trajectory of the work culture, the product, and lives of its employees.

Good people like to work with other good people. Kind people like to work with other kind people. Smart people want to work with other smart people. Abilities and personalities of those around them matter. You spend much of your life outside of the home at an office with others learning, chatting, commiserating.

It’s a mess

After reading Daniel Kahneman’s Thinking Fast and Slow, I came away with a strong desire to improve the way I interview job candidates. He lays out in one chapter some things he learned from interviewing recruits for the Israeli military (Nobel Laureate Says There’s A Better Way To Make Hiring Decisions).

In the chapter, Kahneman outlines how he removed subjectivity and intuition from the evaluation system for the Israeli Army. The system involves measuring 6 categories subjectively and using the scoring to determine the best candidates. Part of this involves proper preparation and consistent execution.

The threat of intuition and emotion

Feelings are bad. I don’t mean in general, but certainly in contexts where emotion should be removed. Not to say there’s no place for any emotion in the interview process, wait no – that is what I’m saying.

Objectively measuring the core attributes you most desire will give you a template to determine who to hire and how to improve your hiring process. I’ve taken to creating a matrix (just Google “interview matrix” and you’ll find plenty of examples) where the y-axis consists of the areas of expertise grouped into 6 of the categories we hold most important and the x-axis represents a graded scale for the subjects.

Some examples of the y-axis would be knowledge of SQL, knowledge of computational complexity and algorithms, Object Oriented Architecture while on the x-axis would be a simple 0-5 scale where 0 represents never even hearing of the subject to 5 being a knowledge expert.

I’ve been met numerous times with people who believe that soft skills can’t be measured, but this is usually because people are unwilling or lack the imagination necessary for coming up with the ways to measure these skills. Anything that can be thought and articulated can in some way be measured. If the position requires speaking skills, assign a presentation and grade the experience. If the position requires the ability to mentor and teach, have the candidate teach you or a junior employee a new topic and have student grade the experience.

The script

The content you use to determine these measurements is as important as what you put on the matrix to measure.

I’ve tried to compile a couple questions grouped for each subject’s scale points. SQL-0 is simple – have you heard of the SQL language? For SQL scale 1 and above, I try to have 2-3 questions to make sure you’re not creating some selection bias about what you specifically know.

Hire people better than you

Somewhat tangential, but just as important is the willingness of interviewers to hire people better than them. It’s best to start this method with senior members who have the ability to measure these aspects most effectively.

Humbleness in the process is key. I aim to find people who will beat me at most aspects of the matrix or I have failed as an interviewer. People better than you can teach you new things, inspire others to join the company, and raise the level of everyone who works with them.

Lessons on a theme

Sometimes you learn the most when you ask questions.

Good stuff happens when:

  • Things get done
  • Testing is added
  • You lead the way for the broader engineering team
  • A balance is struck with coding and deliverables
  • You care about metrics and errors

Bad stuff happens when:

  • A strong hand is missing
  • You are re-inventing the wheel instead of learning or using others’ code
  • Code hygiene isn’t considered
  • Work tries to predict future behavior
  • Promised goals go undelivered