My wife is getting her PhD in Psychology, and a few months ago she was in need of a statistics program called SPSS. There are many questionable avenues one could travel to obtain a copy of this software, which costs over $600, but being a developer myself I purchase all of my software legitimately.
I was lucky; I found a used copy of the student version on Amazon for $87. But my wife soon found that it lacked the features necessary to run the stats for her dissertation. So back to Amazon I went, but, unfortunately, the full version was nowhere to be found.
The Sale
After over an hour of searching and three phone calls, I found out that she didn’t need to pay for the full version (which runs $600), because there is something called a “Grad Pack” that would provide her with the full version for right around $200. “Piece of cake,” I thought, “I’ll buy this copy and re-sell the student version on Amazon.” Things were looking better and better by the minute. Until I posted the student version on Amazon.
Baltimore, MD “We see a need for project managers, senior quality assurance/testers, web developers, and software engineers. Help desk and desktop support work is also starting to come on strong.”
Boston, MA “…in-demand job titles: business analysts, project managers, developers (JAVA and .net), systems administrators (UNIX, Windows, DBA), systems engineers, network engineers, IT security personnel, and storage consultants.”
Chicago, IL “[most in-demand are] project managers, developers, network engineers/administrators, SAP, QA, and programmers specializing in .NET, SQL, JAVA, J2EE, and C++.”
Denver, CO “…the most requested skill sets are .NET developers and Oracle/SQL server DBAs.”
Detroit, MI “…the most in-demand positions include all levels of consulting and project management, SAP, Oracle, system analysts, and network administrators.”
Hartford, CT “Who is most in demand? .NET web developers, application developers, business managers, and project managers…”
Los Angeles, CA “What’s hottest right now? According to MacKinnon, it’s project management and business analyst positions.” (Although my experience is that experienced .NET developers are in huge demand in L.A.)
Silicon Valley, CA “…heaviest demand for: .NET developers, software developers, business analysts, project managers, QA experts, desktop support experts, data warehousing experts, and interface developers.”
I’ve worked for startups and stalwarts, small shops and large corporations, firms where software is the means to an end, and firms where it was an end in itself. After years of exploring what I love about building software I’ve realized that coding for a 17-person dot com is a far cry from building enterprise software for a 300-person credit card company. It only took me eight years to figure out why.
There are a myriad of articles on interviewing, evaluating, and hiring software developers, but a topic that’s rarely discussed is how to attract software developers that fit your company’s environment. With the current state of the software job market, it’s critical as a hirer that you determine not only what type of developers will be happy in your environment (your “developer demographic”), but how you can become more attractive to that particular slice of the market.
Your Developer Demographic As an example, IndyMac and Countrywide are large financial institutions with development offices in Los Angeles. They attract people looking for stable jobs with good benefits where they can code 9 to 5 and then go home and not think about it from 5 to 9. I envy people who do not grow bored with this environment; I really do. Life would be much, much simpler if I could handle it.
There are also tech startups that attract caffeine-junkies. Long hours with potentially large reward, and the prospect of building something really cool in a short amount of time that could make a difference in peoples’ lives. Or, more likely, be relegated to the failed startup scrap heap. These companies should be looking for people who love using new technology, are typically younger, willing to take risks, and willing to shoot from the hip.
These may be extreme cases, but they illustrate the point: certain attitudes and personality traits play nicely with certain environments. Often, a developer who thrives in one environment will find that she slowly withers away in others.
The Three Dimensions To get more specific, there are three dimensions to a company that most affect the internal environment for a software developer. It’s critical that you know which of these your company falls into, and not only market to, but ensure you can retain developers who fit that demographic. The descriptions of the software developers who like to work at each corporate classification are generalized, but they serve as a guide to get you thinking about the personality of your ideal candidate.
Your company may not match exactly with one of the choices below each dimension, but do your best to categorize it. Many companies start off as one thing and transition to something very different in the first year or two.
Size
Small - Some small companies are startups, and some are 10-year old, profitable, mature businesses that make money hand over fist with 9 employees. Software developers who like small companies are typically social, they like the vibe of knowing everyone, going to lunch with the same people, and knowing that they contribute a great deal to the success or failure of the enterprise.
Large - The bulk of corporate development is for larger companies. They tend to have big teams, lots of process, and decent-sized QA and Change Management teams. Software developers who like large companies tend to enjoy more process, like working on larger teams where they can either lead or be led, and enjoy the possibility for growth that comes with a large organization.
Chaos Level
Stable - Stable companies tend to be, um…stable. They have good benefits, and employees can often get away with working 8 or 9 hour days. Developers who prefer stable companies are likely a little further along in their career, may have a family, like the consistency of coming in to the same office each day, and enjoy their time out of the office when they don’t have to think about software.
Startup - Startups tend to be more risky with the possibility of more reward. The salary may not be as high as that of a stable company, but the stock options will be worth six-figures if you can get your bleeding-edge online calendar out the door before Google’s. Benefits tend to be spotty. The hours are long, but it’s more than worth it for developers who are passionate about technology (read: bring books about ASP.NET to the beach), love building software that matters, and enjoy the camaraderie of working on a team of people who share their interests.
Focus
Software (or a technology that relies on software) - These companies rely on software for their main source of revenue, whether they sell it (Microsoft, Intuit), give it away (Google, Craigslist), or offer it on some type of “pay to play” basis (eBay, salesforce.com). Technology firms that rely on software are companies like Palm, Apple, or the guys who make the fingerprint readers I keep seeing at data centers. Software may not be their main source of income, but they are technology companies and software is critical to their product. Software developers who prefer these types of companies enjoy being around other software people; they like the idea that technology is at the core of their company, and they love that they work on real products that people use. In addition, they relish the fact that software firms tend to live towards the cutting edge and are able to constantly upgrade their skills to the latest and greatest.
Everything Else - These companies make up the majority of companies in the world; their main source of revenue is something other than software - credit cards, lawn furniture - you name it. “Everything else” companies use software to support their business: to track widgets, support their call center, and balance their books. The majority of corporate software jobs are working for companies under this umbrella. Software developers who enjoy this type of company like building applications to support accounting, management, and the people who produce or sell the company’s main product, and they are either very content to know they can go home at night and not think about developing software, or they go home at night and all they think about is they day they can leave the company and work for someone like Google.
Your Company, Your Developer Demographic, Your Job Description Before writing your job description think hard about where you fall in each of the dimensions. Then think twice as hard about the kind of developer who will be happy at your company. Don’t kid yourself; you can convince the 24 year-old tech hot-shot to work for your financial services company by offering him a huge salary, but he’ll be gone in 9 months because you’re using three-year old technology and developing boring (from his perspective), back-office software.
Once you’ve determined who will be happy at your company, write your job description with that person in mind.
You’re a large company with great benefits? Spell it out in bullet points: plain, simple, and official. Play up your stability.
You’re a small startup with no benefits? Use a casual tone and create excitement. Make that 24-year old hot-shot be dying to work for you.
When I was in college I was a professional comic book writer. After numerous submissions I had several stories accepted by three independent comic book companies, all slated for publication.
I even received a $100 advance for one of the stories, with all of them paying royalties on the “back end,” meaning I’d probably wind up making $100 per story if I was lucky. And back then $100 was a lot of…no, let’s face it, even back then $100 was nothing. But I could call myself a professional comic book writer.
On Being a Professional Which is a joke, of course, because I wasn’t a professional. I was writing in a tiny bedroom, typically from 10 at night until 2 in the morning, cranking out a short script every week or two. Sure, I had honed my skills as a writer enough to match the myriad of others trying to make it, but I was not a professional writer. And I’ve had a hard time puting my finger on what it was that distinguished me from those whom I considered “legitimate” comic book writers. It wasn’t the fact that I worked out of a small apartment. Or that I wrote at night.
It was the fact that I didn’t consistently deliver under the pressure of deadlines.
I’m sure I’ll receive a few comments saying that a professional is someone who gets paid for what they do, or someone who does something as their main source of income, or someone who’s easy to work with, or someone who comments their code. Those are some of the components of being a professional, but one of the most important and often overlooked pieces of being a professional is consistently delivering a usable product in the face of deadlines.
How Many Deadlines Must a Man Walk Down… I knew at least two guys who were amazing comic book artists. Both drew as well as the books on the shelves, but neither could draw an entire 22-page comic in a month…and that’s what it takes to be a professional in that game.
I’m not saying if you miss a deadline you’re suddenly an amateur - the continuum is much less binary than it is fuzzy. But during your career, your present job, or the past 6 months, how many deadlines have you hit? How many have you missed?
There are going to be extenuating circumstances. There are going to be times when a third party vendor flops and the project falls apart at the last minute. And there are going to be times when the deadline is set externally and you know from the outset you’ll never hit it. But if you find that there’s always a reason you aren’t hitting deadlines you have to start asking yourself: Is it you?
I know that somewhere between 55 and 90 percent of software projects fail. Missing deadlines is easy; I could get my mom, who knows nothing about software development, to come in and miss project deadlines. Does the fact that she showed up and collected a check make her a professional developer? She’s easy to work with and comments her code.
So here is my question: during your career, your present job, or the past 6 months, how many deadlines have you hit and how many have you missed?
On Tuesday I posted a You Be The Manager scenario about a real group of unmotivated software developers. My reply to the original author was sent several weeks ago, and in retrospect I wish I had included some of the creative thinking many of you offered in the comments. If you haven’t read them I suggest you do; there are some exceptional insights into how to improve (or abandon) the situation.
I took a straight-on approach and offered suggestions for determining why these software developers are unmotivated, and how to start returning motivation to their dismal existence (I say dismal because spending 5 years on an ERP project sounds like the worst thing since hitting yourself in the head with a hammer).
If you’ve been a reader for any length of time you know I don’t condone working overtime as a general practice, but I’ve found that a couple times a year it’s necessary to work extra hours to hit a crucial deadline, and this is the approach I took in my response: that this project is in the final stretch and needs one last “push” for completion.
Here were the thoughts I offered the consultant faced with the scenario of the unmotivated software developers:
“No one wants to fail. If the developers sensed the project would not be completed on time they may have begun to mentally distance themselves from it. Even if they supplied the deadline, did they really believe they would hit it, or did they just spit out a date because they were forced to?
If they believed in the deadline at the beginning and started feeling behind, it surprises me that at least one of them did not start working extra hours. If this is the case, the the company/department might be an “8 to 5″ culture. My immediate thought is that there are 1 or 2 leaders who set that pace and, if they were not present, the others may be willing to work extra hours to hit that deadline (assuming it was reasonable in the first place).
If they never believed the deadline, that’s a major problem. Why would they supply a deadline where they had no buy in? This rings of a lack of faith in their management, or their team’s ability to actually complete the work. After 5 years a lack of faith is not surprising, and it’s not out of the question that they simply made up a deadline to satisfy you.
If they feel like they aren’t able to move forward because of political or “people” issues, someone has to clear them out of the way, and fast.
Does the project sponsor have the respect of the developers? At a company I used to work for the CEO would stop in on a meeting every once in a while during a hard project, and explain why the project was so important to the success of the company. Having a high-level manager who the team respects stop by shows the team that this project has major visibility, and that failure will be noticed. Now, I am vehemently against motivating people through the promise of punishment, but if the team has no accountability and seems to be running on their own schedule then it’s quite possible they could use a little something to get them back on track. BTW - if there is no project sponsor that’s a major red flag and unmotivated developers are the least of your worries.”
An SbR reader contacted me looking for guidance on how to work with a group of un-motivated developers; his email is below (posted with permission).
I will post my reply next Monday, after giving you a chance to weigh in on the situation.
Q: “In the course of providing Change Management consulting services to an owner operated company, I got involved in trying to find out what was happening in their IT department (4 Software Engineers). They are all on salary with full benefits.
The IT Departments absolute priority is to insure the company’s current software and network system is operational. In general the current company system only requires minimal daily maintenance with periodic planned upgrades. Accordingly the Software Developers are able to focus the majority of their time on development of a new ERP software system.
They have been at the project for approximately 5 years. Design is complete and development is underway. After much discussion and prodding I managed to get them to produce a timeline to deployment versus completion. Deployment defined as being able to switch from using the current system to the new system with a minimum of equal functionality to the current system. The timeline is to a specific date versus effort in months. They arrived at the deployment via sophisticated process versus an educated guess so I believe it is realistic.
In my view stakeholders must have a deployment date and developers need a realistic deadline. We have our deployment date (set by the developers, not stakeholders) but I suspect they are not committed to it. They start at 8:00 am on the dot and are out the door at 5:00 pm. Lunch and coffee breaks are never missed. My concern is that they have been spoiled by not previously having a definitive deployment date so it is expected to balk at accountability.
My instinct is to shut the project down but I also do not like to give up.
[I’m looking for] direction on how to motivate this group to want to take ownership and to rise to the challenge of meeting the deployment date.”
If you were in his shoes, how would you handle this situation?
What is your advice on becoming a good programmer?
How do you acquire the knowledge?
Is it necessary to know mathematics, specifically algebra, to be a good programmer?
I receive several emails per month along these lines, so I’ve decided to share my advice on the subject. Note that I said “my advice” and not “the one and only way”; there are too many paths for one person to know them all. Here are some thoughts based on my experience:
Q: What is your advice on becoming a good programmer?
Everyone I’ve talked to has taken a different path. Programming is different from other engineering disciplines; if you want to become an electrical engineer you go to school, graduate, work for an engineering firm, and one day take a test and get licensed. Programming is different because people do it as a hobby; no one designs electrical subsystems for fun. This creates more possibilities for learning how to code.
Here are the elements I think are key:
Learn, learn, learn. You must have an insatiable appetite for knowledge. This usually means reading a programming book every few weeks in the early days, and moving on to more conceptual books like The Pragmatic Programmer, Code Complete, and Facts and Fallacies after 6-12 months of full-time coding. I can’t stress enough the value of reading, nor the value of immersing yourself in code early in the process.
Transition into Concepts. Learning how to be a good programmer begins with learning logic concepts and language syntax; they are much easier to understand when taken together. But good developers quickly desire knowledge that transcends language syntax. Perl, PHP, Java, ColdFusion, ASP…all languages I used in my first 18 months as a professional programmer. What made me a good programmer was not my knowledge of each language, but my desire to understand and refine concepts like D.R.Y., the broken window theory, and code re-use.
Hang Out With Programmers Who Are Better Than You. As a guitar player, the most I ever learned about the craft of songwriting was when I was hanging out with people who were much better than I. The same goes for writing software. And due to this new-fangled internet thingy you don’t even have to be physically present to be a part of the community: read programming blogs from the heavy hitters (Scott Guthrie, Rocky Lhotka, Dino Esposito, Scott Mitchell, etc…), check out programming forums, and look at other peoples’ code. Reading source code can be a pain, but the more you see the more you will be able to identity code that’s easy to understand, and code that takes a PhD to figure out how they output “Hello World” to the screen.
Q: How do you acquire the necessary knowledge?
There are a number of possibilities:
A Software Apprenticeship. If you haven’t ready my article on Software Apprenticeships, I recommend you do. The best (and I would argue the quickest) way to become a good programmer is to write code under the wing of an experienced developer who will teach you not only the basics, but the in-depth knowledge that takes years of experience to learn. I consider this option leaps and bounds above all others.
Learning while Doing. Want to learn to code? Get a job writing code. I don’t care if you make $5 an hour; you will progress more in 1 month as a full-time developer than you will in a year of hobby programming. There’s no better way to learn to program than to write code.
Books & Mags. Books and magazines have been key in my quest for programming knowledge. When I’ve apprenticed developers in the past, I use books as their primary source of basic knowledge, having them read 1-2 programming books per month, while teaching them more advanced techniques in person.
College. Having gone this route myself I am well aware of the limitations of the U.S. College system in preparing students for a career in computer programming. Preparing them for a career in determining little-o and big-O notation, sure, but actually writing code from the get go? Nope. College is great for high-level theory, but work experience trounces it when it comes to learning software development.
Tech school. I’ve only worked with one programmer who went to a technical school and she had good knowledge of language and coding concepts, but not a ton of theory or design knowledge. As a result, her code was utilitarian and used a lot of brute-force, but was often not well-designed or easily maintainable. There’s obviously a balance between not enough practical knowledge (college) and not enough theoretical knowledge (tech school). I am using a very narrow sample, so don’t take this as a blanket judgment of tech schools. Perhaps an SbR reader with more experience in this area can enlighten us. As an aside, the network administrators I’ve worked with from tech school have been well-trained and great to work with. Perhaps the nuts and bolts of networking are better suited for such a practical teaching approach.
Q: Is it necessary to know mathematics, specifically algebra, to be a good programmer?
Quite simply, no; it’s not necessary to know math in order to be a programmer.
If you’re developing games, then mathematics and physics play a large part, but building an invoicing application does not require much beyond basic addition and subtraction.
However, from personal experience, people who have an easy time learning mathematics and enjoy solving logic problems (be they algebra or how to move Mount Fuji), tend to learn code quicker and enjoy it more in the long run. It takes a twisted mind, my friends.
To give you more information on becoming a programmer I’m writing an eBook about “How to Become a Programmer,” and I need to know your single biggest question about becoming a programmer.
Ask me a question and you’ll receive 75% off when the eBook is released! (even if you don’t ask a question, enter your email and you’ll get a huge discount when it’s available).
“I lived in Rochester, NY for a very long time and quickly became what I would call a big fish in a little pond. I was great at what I did, but finding a new job that I was interested in was next to impossible.”
My wife and I have talked several time about moving out of a major city and into a smaller one, but I have a hard time believing I would be able to find the type of work I need to keep me excited, especially since I’m no longer satisifed to be a corporate programmer in a dark cubicle. How much room is there for a young technology hotshot in a town of 50,000 (the population of Hattiesburg)?
For some people the small city set-up is great. People who want a nice family-oriented lifestyle, low cost of living, and don’t necessarily get a ton of enjoyment or anxiety out of their work, could be forever happy with a small city/town lifestyle. I have a number of friends who fit this description, and I could see them moving to a place like Hattiesburg or Rochester. Honestly, I often wish I were one of those people.
And then there are those who have what I call a “divine restlessness.” It’s the blessing and curse that makes certain people have to strive for achievement and be constantly learning to stay interested, entertained, and happy in work work and in life. I am definitely afflicted with the latter, and thus smaller-city life is probably not for me.
When it comes down to it, small city life vs. big city life is a matter of taste. And the key to staying happy with your career is to know your own taste beyond the shadow of a doubt.
I have a friend who works for BearingPoint (formerly KPMG Consulting), and she wrote to tell me about her firm’s newest Global Development Center (which are basically off-shore, low cost software development offices). They currently have centers in India and China, and their next destination is…Mississippi. That’s right, a Global Development Center in Hattiesburg, Mississippi.
It turns out Mississippi has a low cost of living (thus low wages) and satisfies the need for clients like the federal government that require work be done in the U.S.
From a financial perspective (though some might call it greed) this seems like a logical trend for some businesses to follow, and similar to one call centers travelled in the 1980s before the internet made “around the world” into “down the block.” But as a fellow developer I’m curious to hear your thoughts on the following questions:
Is it a good thing that development work is moving to low-cost areas, but staying within the U.S.?
Is this a savvy business move made to keep a company competitive, or a devious, greedy move made to take advantage of developers and pocket fistfuls of cash?
Would you be interested in moving to a low cost area of the U.S. (read: the middle of nowhere) and working for less money, but having a better quality of life with no traffic and cheap housing?
After publishing Nine Things Developers Want More Than Money late last year, I received several requests for something that could provide more specific information than the 1-9 score on Rob’s Criteria for Keeping Your Developers Happy. In other words, managers want to know which of the nine areas to focus on, and most who wrote suggested I create a survey they could give anonymously to their developers.
In response, I’ve created a 29-question survey that covers all nine of Rob’s Criteria. I built it in HTML so you can print it out and distribute paper copies, or write code to place the responses in a database for easier analysis. If you wind up using a database I’d appreciate if you would send me a copy of your code so I can post it here.
The survey does not have a norm since it has not been administered to anyone. As a result, determining the results will be up to your interpretation. Hopefully that’s not too difficult given the nature of the questions.
If you have other questions you’d like included, or stories to share about survey results, please post them in the comments.