This is going to be a tough question, and I suspect many won’t like the anwer.
Are you working yourself out of a career?
If this question confuses you, chances are you are doing just this. Perhaps you’re the main guy or gal on your project, and your company values your work (for now). What is your work? Are you doing the same thing day after day? Maintaining Oracle Forms? Updating a legacy web site? Parsing through line after line of Visual Basic to keep some legacy system running smooth?
If so, what else are you working on? Anything?
I remember all too well the dark days of 2001 through 2003, when, just after the dot-com bubble, many skilled software developers were out of work with no good options. Any companies that happened to be hiring took full advantage of the fact that the market for software people was flush with resumes of people who were desperate for jobs. The pay dropped dramatically. I lost my job at a startup that failed, and took the first job offer that came along: A technical writer and quality assurance contractor on a federally-funded project. The job, initially, was horribly boring. I literally hated what I was going–but it was a job.
My problem was, being somewhat young, I didn’t have a powerful resume or much experience under my belt. I didn’t have the proof, so to speak, to convey to a potential employer that I would be a great fit for a position. And the sad fact was that, no matter how great I might have been for a job (so I thought), or how hard I was willing to work, there were literally thousands of other candidates out there. The hiring companies had their pick–and believe me–they were picky!
As good as things seem to be for software developers right now, I’ve learned that the market can change quickly. So it is on you to make sure that your skills are diverse and up-to-date. To that end, it is necessary to continually pursue new learning. Let’s face it: Your employer does not have a vested interest in seeing you grow your career. An employer wants an employee to meet their needs as efficiently as possible. That’s fine. Expected, really.
So what are you doing to ensure that you are valuable when the time comes that your employer no longer needs you, or when your employer downsizes or go goes out of business? It’s a question that many of us don’t wish to ponder too much. It sounds so negative, doesn’t it? But it’s an important question.
It isn’t bad to be an expert at something. It’s great, for example, to be an expert C++ programmer. Kudos! But what does ‘expert’ mean exactly? Does it mean that you do one thing very well, but nothing else? It may mean that you are valuable as a C++ programmer, but of no value when it comes to other needs: UI design, Database Design, jQuery, HTML5, Agile, System Administration. A hiring manager would rather hire a candidate with many diverse skills (yet expert in none of them) than an expert in a single skill.
In a single week at work I find myself working on OS scripts, front-end UI design, back-end data access, business services and Rest APIs. My position requires that I have knowledge of the “full stack” (A term I despise!) as some like to call it. This is good. I feel secure in knowing that I’m hire-able (not to sound self-satisfied) based on a wealth of skills. Should I find myself looking (I’m currently quite content), I’ve built my resume up to show that, while I’m an expert in nothing, I’m skilled in many things. This is a better way to go.
This is a topic that I plan to write more about, perhaps turning it into an article. I want to leave with this, and this is going to sound a little negative if taken the wrong way: If you have been doing the same thing day in and day out for X years, you have not gained X years of experience. You’ve gained 1 year of experience X times in a row. It may be time to consider looking for a new job right now–while employers are eager to find talented software developers. And not just any new job. You need to find a job that will challenge you–stretch you to learn and grow new skills.
(I hope this post doesn’t strike anyone as self-righteous, cynical, or rude. My intent is only to point out a common problem in the career of software developers.)
I have an idea for an article, but I’m not entirely sure how to approach. It’s a subject that I believe some have written about, but as a male, it isn’t a subject that I have given much though to until recently: Where are all the female software engineers?
I suppose the only reason I’ve thought about it at all is because I have two daughters, neither of whom seem all that interested in video games or computers. Sure, there’s some passing interest. They like simple games on Friv. But really, for the most part, any interest in that which may be considered “technical,” ends once they get Pandora open and playing their songs.
I’m definitely not one to declare this an open and cut case of sexism. It could simply be a difference among genders. As someone who loved Lego as a boy, I tried pushing Legos on my daughters. It didn’t stick. I’ve presented video games. No dice. They’ve watching me tinker with Arduino… With only passing interest.
In college I had two female computer science professors. One taught Cobol, the other taught Data Structures, Object-Oriented Programming, C, and C++. This second professor, not a PhD, was one of the best professors I had. She knew her stuff–and she knew how to teach it. Sure, most professors know what they are talking about, but the skill of teaching is something, at least in my experience, that most lack.
I’m trying to think of how many female software engineers I have worked with over the years. I’ve worked with female managers, product and project managers, quality assurance engineers, and technical writers. But when it comes to counting the number of female software engineers I’ve encountered, I think the number is two or three (and only two that I can recall). I do know another female who majored in Computer Science, entered the workforce, worked for IBM, and left the field because she hated it.
While sexism, I think, is an oversimplified answer, I think that simple gender preference is equally oversimplified. After all, there are many female scientists, math teachers, and engineers of other disciplines. May it have something to do with social nature? One can only guess. One would expect just about any professional field to be weighted one way or the other. We aren’t surprised that there are more female than male nurses, or more male than female auto-mechanics. But in these fields, the reason for a gender preference seems somehow a little more clear.
I may not give this a second thought if I had encountered just a few more female software developers. But just two or three seems low enough to suggest that there is something more at play. I don’t suggest for one minute that it has anything to do with bias on the part of men, and I can say this because I personally have not encountered any such bias. I have never once heard men discuss female engineers of any kind in any derogatory manner, nor would I take part in such a conversation (I have a mom, two sisters, a wife, and two daughters–all of them extremely intelligent). Nor do I suggest that the measure of gender equality is equal numbers of men and women in a given field. I think that assumption would be outrageous (correlation doesn’t imply causality, nor does correlation necessarily imply inequality–it may or may not).
About a year ago I was helping my oldest daughter with her math homework. I was shocked when she said, “Dad, I’m just a girl, I’m not good at math.” WHAT! Where in the world would she have heard such a thing? Certainly not from me. Certainly not from any of her teachers (all of them female). When pressed, she could not explain to me why she thought such a thing or where she might have heard it. The only answer I got was, “Math is for boys.” Similarly, I wonder, if for some reason, young girls develop a sense that computers are for boys. And if so, where would this troubling idea come from?
I’m interested in hearing some thoughts on this subject, and if any female software folks happen across this post, I would be especially eager to hear from you.
NY Times has an article about working at Google: Looking for a Lesson in Google’s Perks.
- private reading areas
- comfy chairs (take your laptop elsewhere for a change of environment)
- custom workspaces (let employees choose their equipment)
- fitness classes
- in-house courses (on a range of subjects)
- free food/snacks
All of this is designed to make the workplace one that is both fun and productive. Of course, in a company with the size and profits of Google, such things seem to work very well. From the article:
Ben Waber, who has a Ph.D. from M.I.T. and is the author of “People Analytics,” is, at 29, the median age of Google employees. His company, Sociometric Solutions in Boston, uses data to assess workplace interactions. “Google has really been out front in this field,” he said. “They’ve looked at the data to see how people are collaborating. Physical space is the biggest lever to encourage collaboration. And the data are clear that the biggest driver of performance in complex industries like software is serendipitous interaction. For this to happen, you also need to shape a community. That means if you’re stressed, there’s someone to help, to take up the slack. If you’re surrounded by friends, you’re happier, you’re more loyal, you’re more productive. Google looks at this holistically. It’s the antithesis of the old factory model, where people were just cogs in a machine.”
The overall tone (and the article is written somewhat as a response to Yahoo’s recent clampdown on working from home), it seems that the goal at Google is to inspire people to enjoy work and collaborate more effectively. Read the rest of this entry »
During nearly ever job interview I’ve ever had, on the phone or face-to-face, I’ve been asked some form of the question, “How do you keep your experience current?”
Sometimes (emphasis on sometimes) this is asked by someone who seems impressed that I have such knowledge on a fair amount of “new stuff.” More often this is a genuine question (and a very good one) asked of an interviewee in an effort to gauge the type of software engineer that this candidate may be. Does this candidate have a desire to keep current with emerging trends? In many ways this is a unique necessity in the world of software engineering as a career.
Software engineering is a discipline that requires a real love of the work. Its not something that anyone hoping to find easy employment stability along with a solid paycheck should pursue (warning to those considering Computer Science).
So the question remains: How do you “keep current?”
No matter how much I love software, the fact remains that I have a life outside of work: family, friends, hobbies… Its not easy, but its necessary. One guy suggests learning a language every year. I like to pick up books that look interesting, read Stack Overflow and listen to podcasts. Woe to the “software engineer” who wishes to dismiss all emerging technologies as gimmicks or buzzwords… Such engineers will quickly find themselves (if lucky) performing maintenance work on antiquated legacy code. As long as software is something of a hobby, something that is personally rewarding, all of the above should be easy enough.
While all of the above is good, and its even better to have a pet project, I have found that nothing compares to working around extremely intelligent people for a company that is serious about software.
I recently interviewed with a number of companies for a number of positions. Some of these interviews were phone screens and some face-to-face. A few times I was asked some very specific “test” type questions which, as a good Java programmer, I should know. Sadly, more than a few times, I fumbled for an answer… Its frustrating to be asked a question that you know the answer to but fail response correctly. Its an even worse feeling to not know the answer at all (regardless of the fact that you have done it 1,000 times), but know you have the capability.
In one interview I was asked to describe the difference between an abstract class and a template in Java. On another occasion I was asked to describe the difference between and inner and outer join. I know the answer to each question, but I messed up during the interview, and I came across looking as if I didn’t know what I was talking about.
During another interview I was asked specifics about how and why I made decisions about system architecture, what technologies I chose and why I chose certain directions. I was asked what open source tools I used. This, to me, seemed like a much more appropriate series of questions. It gave the interviewer a chance to understand my thought process, and see that I have the ability to put concepts to practice. It didn’t put my on the spot, asking a pass or fail question (of which I may know the answer to, but flub).
I’m not saying good programmers shouldn’t be able to answer questions like those I listed above. In fact they should be able to. I’m suggesting, having sat on both sides of the interview table, that the latter approach provides a much better analysis of the candidate.
Kandice Rupert, Kandi Rupert, Kandi Kasper, Kandice Kasper
I want to write more about this article when I get a chance. Having recently been back on the job market I have some opinions about this. I don’t think there is a shortage of IT workers. Rather, I think there is a shortage of GOOD ones.
I came across this guy’s blog post titled “10 Things Every Good Web Developer Should Know.” The post is geared toward web developers, but it did get me thinking a bit about the more general questions. I’ve noticed shortcomings among developers (myself included) for a many years. What are some of the things that all GOOD developers SHOULD be expected to know? This list is hardly comprehensive, but I can think of a few things right away:
If you can’t do basic editing in vi you may find yourself in for a world of hurt at some point. I’ve known many programmers who attempt to write software in the safety of their IDE running on Windows only to find severe problems when it comes time to deploy on the server (and the server is typically some flavor of Linux). I recall a fellow software engineering student in my college days saying of his code, “It all works, it just won’t compile!” It sounds silly, right? Assuming software that is written, build and deployed in Windows will built and deploy just fine in another OS is equally as silly (yes, this goes for Java as well).
2. How to debug
Duh, right? Not so. I have helped many, many engineers with basic debugging. I don’t know if it is that I am particularly good at debugging (I’d like to think so), or that (some) others are particularly poor at it, but for most of my career I’ve heard, “Matt, this isn’t working, can you help?”
Generally this question is asked by an engineer who has spend a fair amount of time staring at the screen hoping to gain some diving inspiration and fix a bug. It never works this way. You have to be willing to dig into the code and actually find where the error is. Look through that stack trace! Run the debugger! When all else fails, start sticking print lines all over your code! Staring at the screen will rarely reveal a complex bug. A compile error, sure, but a bug, no.
3. Basic knowledge of C/C++ and or Assembly
In the day of virtual machines, powerful IDEs, scripted languages, OOAD and encapsulation on top of encapsulation on top of encapsulation, it can be too easy to write code and never understand exactly how much stuff has to happen for that code to work its magic. I have not written anything in assembly since college, and I have not written C code for 10 years, but I rely on my knowledge of the low-level “stuff” every time I write code. It helps to understand fundamentals of computer science, optimization, memory handling and what exactly makes all the magic of a 4GL come together. Many people get by without knowledge of assembly language, sure, but these people will not be “superstar” engineers… They’ll be programmers.
4. Version Control
There’s no excuse for not using version control. I would say it borders on negligent not to.
This one may seem like another no-brainer, but I have run into many developers over the course of my career who simply do not have anything more than the most basic understanding of HTML.
6. System Administration
Just the other day sendmail quit working for me. I use sendmail to alert the team about project activity in Redmine, Subversion and Jenkins CI. I run project management software that is served using Ruby and Rails, Apache and Tomcat. I have written perl scripts for handling batch jobs and specialized email alerts. I have written bash scripts that tie in to various subversion triggers. I have installed Ant, Maven, Git, Subversion, Tomcat, Apache, GTK, GCC… You name it… All with NO help from a Linux administrator. Like it or not, these activities become the responsibility of the lead software engineer. If you embrace it and enjoy it, life will be easy. If you are lost, and waiting for the help of a system administrator, you may be in for a very long wait!
7. Database Design
EVERY good programmer MUST understand things likes normalization, joins, foreign keys, natural keys, sequences, race conditions, locking, and on and on. We cannot rely on a database designer. Even the largest companies I have worked for have, the ones with database administrators, have little if anything to say about database design. Database design is the responsibility of the software engineer. A poor design can cripple what may otherwise be good software.
8. Quality Assurance
Our goal as engineers it to deliver a high quality product with no defects. We all know that there will be defects, but this fact does not change the goal.
9. Communication, Documentation, Technical Writing
Even if your company does have the means to hire a dedicated technical writer, that employee will have no idea what your code is doing. Strong documentation is on the engineer (us). I never had to take a technical writing class in college. Fortunately, writing is something I enjoy. For the engineer who hopes to never have to write a document, he or she is likely to be very annoyed in this career.
The Peter Principle says, basically, that people are promoted until reaching a level of incompetence. I think the reverse of this can be true as well: An employee may not be promoted because he or she performs very well in a given role.
This is just me talking, but I think there are a few problems with the way we view employment hierarchies in the software engineering world:
- Managers never knew software development
- Managers who used to know software development have been away from it for so long that they no longer know it
- Developers don’t know management
- There is no clear promotional path for the motivated software engineer
I’ve known a number of software developers who have either turned down promotion or given up a management role because they preferred software development. I suspect then, that the people left to do software management are either people who didn’t like software development or were not very good at it. This isn’t to say that they aren’t great managers (they may be), but it does lead to the possibility that the people in charge of software decisions may not be the best equipped to make those decisions.
Managers Never Knew Software Development
These days many large companies like to assign a PMP to a software project. This is an individual whose job is only to “manage a project.” The individual contributors of the team (software developers, testers, writers, etc.) don’t actually report to this person. The project manager’s role is specifically to work on timelines, track progress and ask the people who are working diligently to report their status (presumably for input into the timelies). If the company doesn’t have a dedicated project manager, this set of tasks falls onto the shoulders of some other manager.
What ultimately happens is that a lead developer will be tapped for all this information anyway, since the project manager, who doesn’t know software development and isn’t writing software, isn’t equipped to provide a meaningful level of detail in this regard. Interrupting a software engineer to ask his “status.” achieves nothing that a good project plan and appropriately used ticketing and version control system cannot.
That said, a good project manager is an individual who knows and understands software development and can provide project status details to upper management without constantly interrupting a team. I’ll take it a step further: I don’t think there is ever a need to have a project manager on a team who isn’t in some way directly contributing to team goals. This doesn’t mean that the project manager must also be a software engineer, but the project manager should be a product contributor. Creating timelines, scheduling meetings and asking people, “When will you be done with that?” is not a full time job!
Yes, we may need a “project manager,” but only if the amount of work is so significant that project management activities are warranted. A better model, in my mind, is to have the group manager, that person who is responsible for the project, have a working team lead for each subgroup. In many cases I think a single team lead of all activities (software, QA, documentation) can suffice.
Managers Who USED TO Know Software Development
Here’s something that annoys me to no end: For a software engineer to take his or her career to the next level, moving into management, seems to require giving up on ever actually engineering software again (at least in the workplace). Ironically, the very people who are required to be hands-off are also expected to make major decisions about software, while their software expertise dwindles. Software engineering is a unique discipline in this regard. As a friend of mine recently put it, it is one of the few careers in which those of us involved with it essentially learn all new stuff every 5 year years.
I find this strange because, in my experience, there very best software leader is not the MBA or the person who has never been a software engineer, rather, it is someone who is STILL a software engineer; Its someone who knows what is going on in the world of Ruby, Rails, Grails, Hibernate, Spring, JQuery, Clojure, , Git, Maven, etc. because he/she is someone who uses such things regularly. The manager whose most recent software engineering experience is a string as a Cobol developer on an AS400 years ago isn’t very well equipped to make assumptions about the effort involded with a web application, for example. 20 years from now I don’t want to be telling some junior developer how easy a project should be because “I wrote the same thing in Java in 2 days back in 2010.”
No Clear Career Path
What I’m getting at is this: A software engineer NOT have to give up writing software in order to move into management (even beyond the lead engineer role). On the contrary–I think it would be better if software management, from director on down, included actual software engineering.
This is a somewhat old article (2006), but it eludes to something that I have found a bit bothersome about attitudes regarding software engineering career paths.
I recently interviewed for a Business Analyst position with the CIO of a large multi-national software development firm. This man was in charge of the company’s worldwide IT operations, including offshore development projects, for which he was searching for qualified Business Analysts. The interview quickly became a casual conversation about current trends within the IT service sector, how the company was planning to take advantage of those trends, and, most importantly, how I could fit into those plans. It was during his evaluation of my skills that I asked how I fit and whether it was technical or business skills that were most valuable to his projects. The CIO summed up his advice about my career path with one small sentence: “Stay on the business side.”
The author goes on to state:
My job searches have suggested that business and systems analysts with a good programming background and a high-level of “business savvy” are becoming the next hot ticket. More and more organizations are finally hiring business analysts to explore, record, and recommend systems that fit the business—as opposed to the other way around.
While I agree with what the author is trying to say here, I think he missed the point. And the CIO quoted above is severely mistaken… Sure, you can train anyone to “be technical” and write a program, but you cannot train those people to do it well. There is a
big huge critical difference between a software developer and a good software developer. I first observed this in college, when some of my classmates loved working on programming assignments and performed very well on such things, while others fumbled through the simplest assignments, unable to get their code to compile, much less work.
Why were such people majoring in computer science? I’m not sure, but its probably because they thought they liked computers and would therefor like programming, or maybe because they heard it would make for a good career.
I don’t mean to pat myself on the back, but I (like many others in my field) didn’t realize that software engineering may be a good career until I was well into my Computer Science major. I started writing simple programs in the 6th grade, going to the library and checking out every single computer and computer programming book I could find. Later, after I had read all of the books that the small local public library had on the subject, I discovered Nibble magazine (also available at the library). Every good/great programmer I know is someone who landed in the career because it was something that he was drawn to naturally, and most of these people began at a young age. These are the people who write software because they like it, and this is why they are good at it.
Anyway, at one point, after being frustrated that my library didn’t have any more computer programming books to read, I found a strangely titled book that had been misplaced next to a book about Applesoft BASIC: The Peter Principle. I checked it out, if only because I thought the title was funny, and I took it home and read it–all of it! I was probably the only 7th grader in the world to ever read the book, which by that time was already very dated. The closest I had ever come to the corporate world by that point in my life was delivering newspapers. I was a fairly competent paperboy, and even if I wasn’t, failing as a paperboy doesn’t lend itself to a very clear path of promotion. That said, the wisdom of The Peter Principle was lost on me.
Little did I know that years later this strange book would be remembered much more vividly than the Applesoft BASIC book that I had checked out dozes of times.
The CIO, probably much older, wiser and richer than me, missed something major: Anyone can write code, but do you want just anyone making important technical decisions that can make or break your project, department or company? I didn’t think so either. Not just anyone can write good code. I’ve seen the results of software written by cheap labor… Indeed, I’ve rewritten code written by cheap labor!
I think there is a very obvious career path for software developers, and it doesn’t necessarily involve moving into a role that no longer includes hands-on software development. I disagree that upper management doesn’t realize this. I think in many organizations they do. I intend to write more on this subject…
I’ve always gotten a chuckle from job posts or emails that state that an employer is search for a “Ninja” or “Genius” programmer. I always assume this to mean that the employer is looking for a single person who can handle an incredible workload alone. I like this video because the presenters (Brian Fitzpatrick and Ben Collins-Sussman) do a great job of explaining the problems that come with viewing a programmer in such a way.