Development Crutches; What Makes a Good Engineer?
Author: Joseph | Filed under: Coding, ProjectsIn my time as a software engineer, I have worked with many people. Over the years, I have met very talented engineers, and done my best to learn from them. I have had four “mentors” throughout my career, in three positions, and they have all been intelligent, helpful individuals that have helped me ramp-up on projects, and enhance my understanding of interesting fields of study. I fondly remember working with Brian Moore and learning a good deal about how the JVM works, especially with regard to garbage collection. My mentor during my internship at Pitney Bowes was very helpful at focusing my fresh-from-college mind to real-world tasks. My coworkers at my current position are all very skilled in their respective areas of IP Telephony, and have been doing this since before I graduated high school. Throughout all of these jobs, all of these people, I have never felt awkward asking a question, and I have been rewarded with bits and pieces of their knowledge over time.
On the other side of this coin, I have also met a handful of people who are not very talented at all. I’ve met “Oracle specialists” who seem to not know the first thing about designing a relational database structure. I’ve seen Java UI designers who can barely write a line of Java code, beyond what their “GUI Builder” creates for them. And I’ve seen engineers claiming to be a “domain expert” in certain things get called out as incorrect by a skilled engineer and a Google search.
There are many explanations as to why such people get hired and kept around. HR people hiring engineers is usually a laughable affair: My friend Pete once got past a HR interview to meet with an engineer, only to find out that the HR rep did not understand the difference between Java and JavaScript. By the time technical managers or engineers enter the hiring processes, the pool of applicants has already been filtered through a non-technical filter. How many good engineers were weeded out? How many bad engineers made it through?
Whatever the cause, they’re there. Every large company has them.
What makes a good engineer anyway?
It’s simple to me, though I bet a lot of people would disagree: All that’s needed to be a good engineer is the ability to learn and adapt quickly. They should understand concepts, and not just specifics. The design of software, and not just the coding of it. How components interact with each other, not the nuts-and-bolts of how to build one.
If a software developer is good, it won’t matter if he’s never programmed in C#. It does not matter if you’re a linux-based Eclipse shop, and he’s used to writing C code on Windows. He won’t be unable to write DirectX code if he’s been working with OpenGL for five years. None of these are limiting factors for an intelligent, skilled engineer. Languages, APIs, and tools are all things a developer can pick up on the way. Where the semicolons go, and what the keywords may be are of no consequence. What matters, what really makes an engineer good, is his ability to understand the system: To see the forest among the trees. Being able to understand the concepts behind the application, before looking at a single line of code, is crucial to being a good software engineer.
When it comes down to it though, the trees matter too. Every software engineer needs to get his hands dirty and sling code, but that is not the core of our profession. Anybody with a “Teach Yourself X in 24 Hours” book can write bad code. Some developers find the name “Coder” derogatory, on par with calling a molecular biologist a “microscope-looker”, or a skilled pianist a “key masher”. I don’t care either way, words being just words, but the point stands: Developing software is a lot more than just writing code.
What I’ve noticed happening recently is that the tools are becoming easier and easier to use, and everyone is growing up in a vastly more computer literate world. It’s entirely possible for a 14 year old girl to fire up Dreamweaver and create a homepage for herself today, or for a 9th grade boy to hack his XBox to play free games. My little brother is sixteen, and while I considered myself technically-minded during my childhood, some of the things he does amazes me.
The common theme here, in my eyes, is that there are Development Tools readily available. Dreamweaver makes designing a fairly complex website fairly painless. Jailbreaking an iPhone requires less clicks than fingers on one hand. Running Linux on a PS3 has been reduced to a bootable CD. Designing a user interface for a program can be done entirely by dragging and dropping control elements.
Skilled engineers and hackers sweat it out, and design tools that make jobs easier, and in turn more accessible. How many people would be pirating XBox games if it required you to write your own drivers, or figure out what wire to soldier to what aftermarket chip? How many websites would have never been made without a WYSIWYG editor like Dreamweaver?
These tools seem like a boon, and for the most part they are. Designing a GUI in Java is fairly painful, writing all the code yourself. Forcing a GridBagLayout to bend to your will can leave you with a serious headache. Being able to design a web page without having to fiddle with the HTML or CSS directly is great for most simple pages. Modern IDEs certainly speed up development time with their real-time error checking, automation, and method autocompletion. Mashing Ctrl+Shift+O and having Eclipse optimize all your imports is a trivial luxury, but one I would not like to go without anymore.
As mentioned before, these tools also increase accessibility. At the risk of sounding like an elitist, accessibility is the enemy.
Bad engineers who get good with tools like these can seem better than they are. They can show you a portfolio of shiny web pages, or some sample GUI designs, and they look pretty good. But how much of it was the developer, and how much the tool? When that web developer is working on your web application, in a complex section where it can’t be loaded into Dreamweaver, what’s going to happen? When you load up that Java GUI that the engineer made in their GUI Tool, what are you going to find? Are objects going to be labeled correctly, or will you find a file with “jLabel72″ defined, and have to figure out what and where that is?
Are these “toolgineers” going to write maintainable code? Are they going to be able to maintain their own code? Do they understand the concepts behind the system, or do they just mash buttons in a tool until something that looks “good enough” comes out? Are they freelance contractors who won’t even care about the product 6 months from now?
These tools can make bad engineers appear passable, and can make good engineers lazy.
These tools are crutches.
Good developers should be wary of these tools. While we should always be open to new tools and ideas that will speed up our development or make us more productive, we should not rely on them too much. We should always keep ourselves sharp, and truly understand all the layers of the application: From the forest to the trees, from concepts to nuts-and-bolts.
Because one day, you might find yourself stuck debugging an issue with nothing more than a shell and vi. Your crutches will be useless then. And when that happens, you’ll wish you haven’t atrophied too much.
2 Responses to “Development Crutches; What Makes a Good Engineer?”
Leave a Reply
You must be logged in to post a comment.
Great article – I totally agree on all points. As for me, I’ve been with the same company for almost five years at this point, but it’s a small office So, I’m coming from a different vantage point: we have been much more careful with hiring than you describe, but being one of a handful of engineers working on one mega-product, I’ve had to be mindful of keeping myself current and growing after spending half a decade in the same chair, because it’s not always going to happen automatically when one of your key strengths is domain expertise.
One of the things I liked most about the RPI computer science program is its balance. I’ve seen programs that produce coders, and I’ve seen programs that produce computer scientists. RPI did well at producing software engineers. We graduated with a good blend of theoretical understanding and real-world know-how, and it’s served us well I think.
“Toolgineers” have a distinct way of working themselves into your life. They start off by being the coworkers you never talk to. The coworkers you assume have their own work and should never have anything to do with your life. The coworkers you pleasantly say “hello” to in the morning and some mediocre watercooler stuff.
But! At some point they’re placed on the same project as you. The politics behind it is that you’re a solid developer and they are not. They need a crutch and you’re it. Most of the time you have no knowledge you’re a crutch. It’s really your manager’s foresight. It only hits you when you’re knee deep in deadlines and all your teammate is good for is writing the status report email every 2 hours (with you of course dictating the status). This person is only delaying you from finishing your work and going home for the day.
The problem is, at the end of the day, that team member is still a person. He still has his/her own family to support. The choice of pointing them out as a hindrance is a serious moral choice. This is especially so in Valley where there are a mass amount developers waiting to replace that one person. Having that person let go is probably easier than imagined too. It just takes a well written complaint towards a few key managers and poof! it’s layoff season again. Spouses and kids that look to them for support have now had their world toppled by a mere complaint, a mere note.
Not saying that you shouldn’t point out a toolgineer if you come across one. It’s just some non-work thoughts. I mean, is not working with that person again worth their hardship? (