Advice From A JUG Leader – Learn A Different Language

The cry of “Java is Dead” has been heard for many years now, yet Java still continues to be among the most used languages/ecosystems.  I am not here to declare that Java is dead (it isn’t and won’t be anytime soon). My opinion, if you haven’t already heard:

Java developers, it’s time to learn something else

First, a little background as basis for my opinions:
I founded the Philadelphia Area Java Users’ Group in March 2000, and for the past 12 years I have served as ‘JUGmaster’. Professionally, I have been a technology recruiter focused on (you guessed it) helping Philadelphia area software companies to hire Java talent since early 1999. I started a new recruiting firm in January that is not focused on Java, and I’m taking searches for mostly Java, Python, Ruby, Scala, Clojure, and mobile talent. This was a natural progression for me, as a portion of my candidate network had already transitioned to other technologies.

I launched Philly JUG based on a recommendation from a candidate, who learned that the old group was dormant. Philly JUG grew from 30 to over 1300 members and we have been recognized twice by Sun as a Top JUG worldwide. This JUG is non-commercial (no product demos, no sales or recruiting activity directed to the group), entirely sponsor-funded, and I have had great success in attracting top Java minds to present for us.

The early signs

After several years of 100% Java-specific presentations at our meetings, I started to notice that an element of the membership requested topics that were not specifically Java EE or SE. I served as the sole judge of what content was appropriate (with requested input from some members), and I allowed the group to stray a bit from our standard fare. First was Practical JRuby back in ’06, but since that was ‘still Java’ there was no controversy. Groovy and Grails in ’08 wasn’t going to raise any eyebrows either. Then in ’09, we had consecutive non-Java meetings – Scala for Jarheads followed by Clojure and the Robot Apocalypse (exact dates for said apocalypse have been redacted). Obviously there is commonality with the JVM, but it was becoming readily apparent that some members of the group were less interested in simply hearing about JSP, EJB, Java ME or whatever the Java vendor universe might be promoting at the time.

I noticed that the members that sought these other topics and attended these alternative meetings were my unofficial advisory committee over the years – the members I called first to ask opinions about topics. These people were the thought leadership of the group. Many of them were early adopters of Java as well.

It was apparent that many of the better Java engineers I knew were choosing to broaden their horizons with new languages, which prompted me to write “Become a Better Java Programmer – Learn Something Else“. That ’09 article served to demonstrate that by learning another language, you should become a better overall engineer and your Java skills should improve just based on some new approaches. Today I go a step farther in my advice for the Java community, and simply say ‘Learn Something Else‘.

To be clear, the reason I make this suggestion is not because I feel Java as a language is going to die off, or that all companies will stop using Java in the near future. Java will obviously be around for many years to come, and the JVM itself will certainly continue to be a valued resource for developers. The reason I advise you to learn something else is that I strongly believe that the marketability of developers that only code in Java will diminish noticeably in the next few years, and the relevance and adoption of Java in new projects will decline. Known Java experts who are at the top few percent probably won’t see decreased demand, but the vast majority of the Java talent pool undoubtedly will.

The writing on the wall

I think at this point the writing on the wall is getting a bit too obvious to ignore, and you have two forces acting concurrently. First, there is a tangible groundswell of support for other languages. A month doesn’t seem to go by that we don’t hear about a new language being released, or read that a company transitioned from Java to another option. Much of this innovation is by former Java enthusiasts, who are often taking the best elements of Java and adding features that were often desired by the Java community but couldn’t get through the process for inclusion.  Java has been lauded for its stability, and the price Java pays for that stability is slowed innovation.

The second contributing factor is that Java has simply lost much of its luster and magic over the past few years. The Sun acquisition was a major factor, as Oracle is viewed as entirely profit-driven, ‘big corporate’, and less focused on community-building than Sun was with Java. The Java community, in turn, is naturally less interested in helping to improve Java under Oracle.  Giving away code or time to Oracle is like ‘working for the man‘ to the Java community.   Oracle deciding to run JavaOne alongside Oracle OpenWorld may have been an omen. Failures such as JavaFX and the inability to keep up with feature demand have not helped either.

My suggestion to learn something else is also rooted in simple economic principles.  I have seen the demand for engineers with certain skills (Ruby, and dare I say JavaScript are good examples) increasing quickly and dramatically, and the low supply of talent in these markets makes it an opportune time to make a move.  It reminds me of the late 90’s when you could earn six-figures if you could spell J-A-V-A.  Some companies are now even willing to teach good Java pros a new language on the job – what is better than getting paid to learn?  The gap in supply and demand for Java was severe years ago, but it seems the supply has caught up recently.  Java development also seems to be a skill that, in my experience, is shipped offshore a bit more than some other languages.

Still don’t see it?  Remember those early Java adopters, the thought leaders I mentioned?  Many of them are still around Java, but they aren’t writing Java code anymore.  They have come to appreciate the features of some of these other offerings, and are either bored or frustrated with Java.  As this set of converts continue to use and evangelize alternative languages in production, they will influence more junior developers who I expect will follow their lead.  The flow of Java developers to other languages will continue to grow, and there is still time to take advantage of the supply shortage in alternative language markets.

Java will never die.  However, the relevance and influence of Java tomorrow is certainly questionable, the marketability of ‘pure’ Java developers will decline, and the market for talent in alternative languages is too strong for proactive career-minded talent to ignore.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Stop Crapping on Startups

Michael O. Church recently wrote a thought provoking blog post, “Don’t Waste Your Time in Crappy Startup Jobs“, and the author clearly put a lot of thought into writing the piece.  Based on the comments and the retweets, it appears the article hit home for quite a few people.  I think the article’s title might sway a reader’s interpretation a bit, or readers may simply see it as ‘Don’t Waste Your Time in a Startup’.  I’m sure that wasn’t the intent of the article, but based on some of the comments, that sentiment seems to be the takeaway for many.

The crux of the article is a list of seven misconceptions that the author chooses to dispel one by one.  I’d like to take each of them and see if these are truly problems with start-ups, problems with the engineering industry, or even problems with expectations.  (Mr. Church’s excerpts are in red, my comments follow)

1. A startup will make you rich. True, for founders, whose equity shares are measured in points. Not true for most employees, who are offered dimes or pennies.”

First, I don’t think most engineers that join startups are expecting to get rich these days, and even founders aren’t all expecting to get rich.  If you had written this in 1999, I’d agree this is a common misconception.  Most employees in my experience see stock options or equity grants as ‘lottery tickets’, that they realize probably won’t pay off – but they also understand that you simply can’t win if you don’t play.

“Moreover, raises and bonuses are very uncommon in startups. It’s typical for high performers to be making the same salary after 3 years as they earned when they started. (What happens to low performers, and to high performers who fail politically? They get fired, often with no warning or severance.) “

I don’t see bonuses or raises as uncommon in the start-ups I’ve worked with.  My current client list includes a handful of startups that all offer bonus, and historically I’ve seen employees getting raises and bonuses from startups that are on par with some of my larger clients.  And low performers being fired without warning or severance?  Is that a startup problem specifically?  Low performers or people who ‘fail politically’ are fired in any sized company, the only difference may be severance.  Again, this is not a ‘crappy startup problem’.

2. The “actual” valuation is several times the official one. “In truth, startup employees should value equity and options at about one-fourth the valuation that VCs will give it. If they’re giving up $25,000 per year in salary, they should only do so in exchange for $100,000 per year (at current valuation) in equity.”

I usually advise candidates that they may want to weigh any equity simply as a chance to receive some additional compensation, and I’d generally advise them not to accept any offer that won’t afford them to live a lifestyle that makes them comfortable.  If you can’t afford a 25K pay cut, don’t take one.

3. If you join a startup early, you’re a shoe-in for executive positions. 

Again, I just don’t think engineers are this naive today to believe this, or at least not the people I know.

“Not so. In fact, one of the best ways not to get a leadership position in a startup is to be there early.”

I’d love to see if any actual scientific evidence exists to back this claim up, but I wouldn’t know where to find it.  For every engineer you can name that did not get a leadership spot, I’m sure someone else can name one that did.  Again, in my experience I generally see that engineers who join early on are rewarded with leadership roles that they are qualified to do.  Being the first or second engineering hire at a startup doesn’t automatically give you the qualifications to be CTO, and if you expect you should be CTO/VP just because you were an early hire you probably need to rethink why you are joining the company.

“Startups often involve, for engineers, very long hours, rapidly changing requirements, and tight deadlines, which means the quality of the code they write is generally very poor in comparison to what they’d be able to produce in saner conditions. It’s not that they’re bad at their jobs, but that it’s almost impossible to produce quality software under those kinds of deadlines.”

True on hours, deadlines, requirements, and perhaps the code could be better in ideal conditions.  I hear anecdotes all the time from engineers at large companies telling me how much free time they have with their highly reasonable deadlines and fully developed requirements being written in stone.  Wait…no I don’t!  Again, not a ‘crappy startup problem’ – it’s the nature of the software game overall, just a bit amplified.

“It may have been a heroic effort to build such a powerful system in so little time, but from an outside perspective, it becomes an embarrassment. It doesn’t make the case for a high-level position.”

From an outside perspective, companies that may hire these engineers down the road will most likely respect the experience those engineers had in building the product under less than ideal conditions.  Most hiring managers from outside firms won’t know whether the product was some epic flop anyway.

“Once the company is rich and the social-climbing mentality (of always wanting “better” people) sets in, the programmers will be replaced with more experienced engineers brought in to ‘scale our infrastructure’… The old engineers probably won’t be fired, but they’ll be sidelined, and more and more people will be hired above them.”

Well that was depressing.  I’d say, more likely, once the product is built and the company can hire more engineers, the developers that were there in the beginning now have accomplished their goal and will make the choice to move on.  The mentality of this type of engineer is to build something, but they may not want to maintain it.  Once that excitement is gone for this type of engineer, they will go voluntarily.

“Frankly put, being a J.A.P. (“Just A Programmer”) in a startup is usually a shitty deal. Unless the company makes unusual cultural efforts to respect engineering talent (as Google and Facebook have) it will devolve into the sort of place where people doing hard things (i.e. software engineers) get the blame and the people who are good at marketing themselves advance.”

Is J.A.P. a great deal at other companies?  There are plenty of established companies that don’t pay engineers great salaries, and work them long hours.  I think the key point is the cultural efforts to respect engineering talent.  My clients tend to love and respect their engineers, which is why I disagree with many of these stereotypes.

4. In startups, there’s no boss. This one’s patently absurd, but often repeated. Those who champion startups often say that one who goes and “works for a company” ends up slaving away for “a boss” or “working for The Man”, whereas startups are a path to autonomy and financial freedom.”

No boss?  I must admit, in my 15 years of tech recruiting I’ve never heard this one before.  Who are these people that you are talking to?  I’d say startups are a potential path to financial freedom, whereas working for an established company (with no ‘lottery tickets’) is probably not going to get you to early retirement.

“People who really don’t want to have “a boss” should not be looking into VC-funded startups. There are great, ethical venture capitalists who wouldn’t go within a million miles of the extortive shenanigans I’ve described above. It’s probably true that most are. Even still, the power relationship between a founder and investor is far more lopsided than that between a typical employee and manager. No manager can legally disrupt an employee’s career outside of one firm; but venture capitalists can (and sometimes do) block people from being fundable.”

How did we get from having ‘no boss’ to extortion by VC’s and managers?  A manager disrupting an employee’s career outside of one firm???  WTF?  Lemme guess...the author had a very bad experience?

5. Engineers at startups will be “changing the world”. With some exceptions, startups are generally not vehicles for world-changing visions. Startups need to think about earning revenue within the existing world, not ‘changing humanity as we know it’.”

This might work on a small subset of 22 year old kids, but I think most people know they aren’t going to change the world.

“…but people should understand that their chances of individually effecting global change, even at a startup, are very small.”

The likelihood of ANYONE effecting global change is incredibly small at a startup, and probably just as small at a large company.  Again, this isn’t a ‘crappy startup problem’.

6. If you work at a startup, you can be a founder next time around. 

Why not?  No, seriously – why not?  Working at a startup doesn’t exclude you from being a founder next time, does it?

“What I’ve said so far is that it’s usually a sh*tty deal to be an employee at a startup: you’re taking high risk and low compensation for a job that (probably) won’t make you rich, lead to an executive position, bring great autonomy, or change the world.”

If you assume there is high risk and low compensation for every startup job, I’d agree.  Jobs with established companies don’t always pay well, rarely make you rich or lead to an exec position, and almost never allow you to change the world.  If that is how you define a crappy job, all jobs are crappy.

7. You’ll learn more in a startup. This last one can be true; I disagree with the contention that it’s always true. Companies tend to regress to the mean as they get bigger, so the outliers on both sides are startups. And there are things that can be learned in the best small companies when they are small that can’t be learned anywhere else. In other words, there are learning opportunities that are very hard to come by outside of a startup.”

So you won’t necessarily learn more in a startup, but there are unique opportunities to learning in a startup.  This sounds like a feature, not a bug.  Are there unique opportunities in larger companies to learn things that you can’t learn anywhere but in the larger company?  Perhaps.

“Startups are generally too busy fighting fires, marketing themselves, and expanding to have time to worry about whether their employees are learning.”

Fighting fires is a great metaphor here.  Do you know the best practice for fighting fires?  It’s actually fighting fires.  Of course, there is danger in that, but engineers learn much more by being in those environments than they do in a completely comfortable setting.  It’s not about a company that can afford (both time and money) to send you to a training seminar, it’s about learning on the startup job how to build something under tough conditions.

CONCLUSION

In conclusion, the problem with Mr. Church’s article isn’t that startup jobs are crappy.  It’s that the author feels that many people may have certain unrealistic expectations about startup jobs.  It assumes that all startups work you to death and pay you nothing, and that simply isn’t the case.  It’s a stereotypical assumption, and it’s dangerous one.

If you take any job and expect that you will absolutely:

1 – get rich
2 – become an executive
3 – have no boss
4 – change the world
5 – found a company within x years
6 – learn more than everyone else

then I can assure you that you will be VERY disappointed, no matter the size or age of your new employer.  I sense that people have more realistic expectations than Mr. Church gives them credit for, and the people I know in 2012 certainly do.  A more appropriate title for his article would have been ‘Don’t Join a Startup with 1998 Expectations’.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Geek Independents

The decision to become an independent consultant in the software world is not something to be taken lightly.  Although the work you will be doing on the job is probably very similar if not identical to what you have done as an employee, you really need to conduct an honest and thorough self-examination to determine if you are cut out for the demands of running a successful consulting business.

After years of working with many independent consultants to help them find gigs, and in many cases serving as counsel for engineers considering the transition from employee to independent, I have compiled a list of traits that are necessary in order to thrive in today’s marketplace.  Conveniently for me, the necessary traits are often associated with body parts (which helps with extended metaphors, bad puns, etc.) – so I give you “What it Takes to Be an Independent Consultant From Head to Toe (but not necessarily in that order)”.

The Stomach – Obviously it takes some guts to leave a steady job and take the plunge into independent work. You need to have confidence that your skills will be in demand by clients, and that you will be able to reach your target audience (hiring managers) either through your own network or via agents/recruiters that you can trust. It also helps to understand that sometimes independents will be ‘between gigs’ – many indies appreciate the ability to take a week or two off before starting a new assignment, but if not carefully choreographed the beauty of an independent’s flexibility can become an undesirable period of unemployment. Being able to digest some weeks without a paycheck is a necessity, even if it never actually happens to you.

The Teeth – Chances are you’ll be asked to cut your teeth on some new technology on every gig. Never expect to be using the same set of languages, tools, databases, operating systems, etc. on every project. The ability to learn new technologies quickly and ‘on the fly’ is essential to your success as an independent. Ask the client what tools you should brush up on a couple weeks before the project starts, and do a little research to hit the ground stumbling if not running.  Invest additional time to keep up with trends and learn new tricks that may be valuable on future gigs.

The Head – We’ll assume you have the head for technology – if not, please stop reading this now and get back to your work! In addition to knowing your way around code, you’ve got to at last have some mind for business. Most tend to leave the tax and legal stuff for the professionals (a decent accountant and lawyer will save you time – good ones might save you jail time!). You also need to have at least some idea of the numbers behind independent work. What do I need as an hourly rate to maintain or improve my lifestyle? Did I factor in some costs that I may not have worried about as a salaried employee (insurance, mileage, parking, taxes)? How much time can I afford to take off without hurting my bottom line?

The Legs – Finding a great gig can take quite a bit of legwork, especially if you decide to go it alone and not use an agent. Even with an agent it can take some time and effort to secure a project, so be prepared to take the search for new assignments just as seriously as the job itself. Be organized in your search, reach out to past clients and touch base with an agent you know and trust. Finding a five year or even two year project is extremely rare, and many gigs are in the six month range.  Thankfully, your job search activities should only happen a couple/few times a year at most.

The Feet – Unless you can find telecommuting positions, independents may have to be more open to locations that may be less than ideal from a commuting perspective. It is always better in the long term to take the project 40 miles away that offers a new marketable skill over the Cobol gig next door. Openness to a bit longer ride will surely enhance your ability to stay utilized/paid.

The Heart – You are the sole representative of your company, so you need to make every interview and client interaction a positive experience even if you don’t get the gig. Walking out of/canceling interviews, leaving assignments without proper notice, or presenting yourself as negative or unfriendly can get you a reputation with both hiring managers and agents, and that will hurt your chances of securing future work. Don’t burn any bridges! Show some love to your clients and they’ll keep you coming back for more work.

The Nose – Getting stuck on a doomed project will happen to almost every independent during their career, but having a nose to smell out rotten gigs will save lots of headaches. Ask the right questions in interviews to learn as much as possible about the team, management, customers, and expectations for delivery.  Then decide if you have a chance to be successful.

The Elbows – Rubbing elbows with fellow software professionals and staying in touch with old contacts should keep you off the bench, and tools like Twitter and LinkedIn make it that much easier to keep connected. Foster relationships with other independents that could potentially find you work when necessary.  If you are active in some open source communities, developing personal relationships with other committers and contributors could lead to referrals.

The Ears and Mouth – The ability to listen to and understand your clients’ requirements is perhaps the most important skill required to be successful as an independent. At the rates you are being paid, there is little margin for error. Get a good req and ask the necessary questions to be sure you are clear as to what is expected and when it needs to be delivered.

The Face – Many successful independents have a reputation in the community as having deep expertise in one certain subject, or while others are regarded as great and well-rounded engineers.  How did they achieve that notoriety?  Independent consultants often choose to be very conscious of their ‘brand’ and to proactively take time to help build and maintain that identity.  Blogging, authoring books or articles, presenting at conferences and user groups, or simply being seen at certain industry events are ways to keep your face out there for potential customers to see.

Do you have the necessary traits to run a successful independent consulting business?

Note:  If this content sounds remotely familiar, I originally wrote parts of this article for a newsletter in 2008.  I made several edits and updates for this posting.

Why You Didn’t Get the Job

Over the course of my career I have scheduled thousands of software engineering interviews with hundreds of hiring managers at a wide array of companies and organizations.  I have learned that although no two managers look for the exact same set of technical skills or behaviors, there are recognizable patterns in the feedback I receive when a candidate is not presented with a job offer.

Obviously, if you are unable to demonstrate the basic fundamental skills for a position (for our purposes, software engineering expertise), anything else that happens during an interview is irrelevant.  For that technical skills assessment, you are generally on your own, as recruiters should not provide candidates with specific technical questions that they will be asked in an interview.

It should be helpful for job seekers to know where others have stumbled in interviews where technical skill was not the sole or even primary reason provided for the candidate’s rejection.  The examples of feedback below are things I have heard repeatedly over the years, and tend to be the leading non-technical causes of failed interviews in the software industry (IMO).

Candidate has wide technical breadth but little depth – The ‘jack of all trades’ response is not uncommon, particularly for folks that have perhaps bounced from job to job a little too much.  Having experience working in diverse technical environments is almost always a positive, but only if you are there long enough to take some deeper skills and experience away with you.  Companies will seek depth in at least some subset of your overall skill set.

Candidate displayed a superiority complex or sense of entitlement – This seems most common when a candidate will subtly (or perhaps not so subtly) express that they may be unwilling to do any tasks aside from new development, such as code maintenance, or when a candidate confesses an interest in exclusively working with a certain subset of technologies.  Candidates that are perceived as team players may mention preferences, but will also be careful to acknowledge their willingness to perform any relevant tasks that need to be done.

Candidate showed a lack of passion – The lack of passion comment has various applications.  Sometimes the candidate is perceived as apathetic about an opportunity or uninterested in the hiring company, or often it is described as what seems to be an overall apathy for the engineering profession (that software is not what they want to be doing).  Regardless of the source of apathy, this perception is hard to overcome.  If a candidate has no passion for the business, the technology, or the people, chances are the interview is a waste of time.

Candidate talked more about the accomplishments of co-workers – This piece of feedback seems to be going viral lately.  Candidates apparently ramble on about other groups that built pieces of their software product, QA, the devops team’s role, and everyone else in the company, yet they fail to dig deep into what their own contribution was.  This signifies to interviewers that perhaps this candidate is either the least productive member of the team or is simply unable to describe their own duties.  Give credit where it is due to your peers, but be sure to focus on your own accomplishments first.

Candidate seems completely unaware of anything that happens beyond his/her desk – Repeatedly using answers such as “I don’t know who built that” or “I’m not sure how that worked” can be an indicator that the candidate is insulated in his/her role, or doesn’t have the curiosity to learn what others are doing in their company.  As most engineering groups tend towards heavy collaboration these days, this lack of information will be a red flag for potential new employers.

Candidate more focused on the tools/technology than on the profession – Although rare, this often troubles managers a great deal, and it’s often a symptom of the ‘fanboy’ complex.  I first experienced this phenomenon when EJB first arrived on the scene in the Java world, and many candidates only wanted to work for companies that were using EJB. When a technologist is more focused on becoming great at a specific tool than becoming a great overall engineer, companies may show some reluctance.  This is a trend that I expect could grow as the number of language/platform choices expands, and as fanatical response and the overall level of polarization of the tech community around certain technologies increases.

Candidate’s claimed/résumé experience ≠ candidate’s actual experience – Embellishing the résumé is nothing new.  A blatant lie on a résumé is obviously a serious no-no, but even some minor exaggerations or vague inaccuracies can come back and bite you.  The most common example is when a candidate includes technologies or buzzwords on a résumé that they know nothing about.  Including items in a skills matrix that are not representative of your current skill set is seen as dishonest by hiring managers.

Candidate’s experience is not ‘transferable’ – If your company is only using homegrown frameworks and proprietary software, or if you have worked in the same company for many years without any fundamental changes in the development environment, this could be you.  The interviewer in this case feels that you may be productive in your current environment, but when given a different set of tools, methodologies, and team members, the candidate may encounter too steep a learning curve.  This is often a response on candidates that have worked within development groups at very large companies for many years.

Give some thought to these before your next interview.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

I Heard That Company Was Horrible (three years ago) – Truth in Company Reputation

Let’s start with a brief exercise.

  1. First, name three companies in your area that you have heard negative details about from other software engineers (sweatshop, poor code base, horrible software processes, buggy product, low salaries, etc.).  Places you would probably never work.
  2. Got it? Now name three companies in your area that you have heard stories about, and you would classify them as great places to work.  Places that you would pick up and leave your job for tomorrow.

If I had to guess I would say that the first question was probably much easier to answer than the second, and the obvious reason is that bad news is sticky and tends to travel fast. There is evidence of why this happens – read about the availability heuristic as an example.  Your ability to recall a co-worker saying his former employer was ‘pleasant’ is lower than your ability to recall him saying that ‘the place was a sweatshop’.  Casual sports fans will know OJ Simpson or Kobe Bryant more about them from tabloid headlines than their impressive athletic statistics. The same goes for anecdotal evidence about technology companies, and unfortunately some technologists miss out on great opportunities based on what is often dated or inaccurate information.

When I start a search for software engineering talent with a new client company, I  know that it is only a matter of time before I will hear a candidate telling me that he/she has heard that my client has flaws. No company is immune, and I always dig deeper to find out what the candidate has heard. Sometimes the information is so outlandish that it can be immediately dismissed, but more often than not there is some truth in the dirt, and it’s important to find out as early as possible about any skeletons in the closet.

When presented with patterns of information that paint my client in an unflattering light, I go to the client with the ‘word on the street’ and ask if there is any merit to the stories. Most shops own up to past sins and how they remedied the situation, or sometimes they say that the issue is still an issue.

Part of the problem is a general mistrust of the messenger (recruiters) by the tech community, with the prevailing thought that recruiters lie.  Some do. Another potential issue is that companies looking to hire tend to describe their environment as they would like it to be and not as it actually is. Self-assessments of work environment, the quality of an engineering team, and internal development process will often be at least slightly biased.  Lastly, the web is a tremendous resource for finding negative opinions on companies from disgruntled former employees, but probably not a great tool for honest company reviews.

The inspiration for this blog post was a discussion I had last week with a candidate.  I was giving him details on a new client company and the candidate told me that he had heard a few years ago that they suffered from high turnover, poor technical leadership, and the engineering staff was overworked.  I told him I would look into this as I had not heard any of it before, and this candidate told me that at this point he was not interested in pursuing the opportunity.

I immediately contacted an engineering director at the client and asked about the feedback.  The manager responded that their turnover was about industry average and provided numbers for the past year.  He told me that there indeed were two managers who were ineffective and they had been released earlier in the year, and the managers that replaced them have received positive reviews from their engineering teams.  Lastly, the manager described several improvements they have made over the past two years to try and appease the development staff.  These changes included the creation of an application support group that would tackle client issues and bug fixes that the development team had previously handled, upgrading the physical office space and equipment, and redesigning the floor plan to increase developer collaboration.

I was quite pleased with this response, as it answered all of my candidate’s concerns while acknowledging that there was some historical truth to the information.  When I shared this information with the candidate, he felt that he would like to pursue the opportunity.  I don’t know if he will or won’t get the job at this point, but his ability to keep an open mind at least gives him the chance to compete for a good career opportunity.

Simply put, a bad reputation or stereotype is difficult for any organization to overcome, even if the information is old or completely inaccurate.  Many companies are able to change with the times and make improvements over time, and technology companies are perhaps more adept at reinventing themselves just based on the ever-changing world of software development.  If you don’t want to miss a potential great opportunity, weigh the evidence you have seen and keep an open mind.

Lessons From a JUG Talk With Eric ‘ESR’ Raymond

(full video of ESR’s presentation from YouTube below this post)

I have been President of the Philadelphia Area Java Users’ Group for 12 years, and as one might expect a typical meeting is geared around a presenter with a slide deck that gives a deep dive into some Java topic.  We could hear a case study, an explanation of a tool, tips for programming effectiveness, etc.   The JUG has followed this model since I founded the group in 2000, and we manage to get between 75-150 attendees at most meetings.

Last month we held a meeting that was entirely different.  I had reached out to Eric Raymond (aka ‘ESR’), who is best known as a leader in the open source software movement and author of The Cathedral and the Bazaar, about potentially speaking to the group.  Although ESR is not commonly associated with Java, I thought it would be an opportunity for the group to hear a well-known and respected engineer speak about a topic.  ESR suggested that he would do a free-form type presentation, without notes and slides, and simply take questions from the audience to use as improv material.  With about 150 engineers in attendance, ESR fielded a fairly wide array of questions on everything from functional languages to open source licensing to coding standards.

So why am I posting this article on JobTipsForGeeks?  As a recruiter I am often asked for career advice by my network of engineers, and my answers are always based much more on market trends (supply and demand) and ‘buzz’ around various technologies than on the viability of the technologies themselves.  For example, I am well qualified to discuss the adoption of specific languages by software companies in my region, but I am much less qualified to discuss the long-term viability of those adoption choices from a technical viewpoint.

As ESR was asked some of the same questions I am often asked, I thought his answers and insights were an opportunity for the audience to hear a ‘technically-grounded’ counterpoint (or supporting evidence) to the market-based advice I provide to individuals.  His specific commentary on functional programming languages and the value of learning them regardless of adoption rate was something I thought was insightful advice for engineers of all levels, and his musings on coding standards and how to obtain management ‘buy-in’ on open source are great tips for navigating at companies that may not be as tech-friendly as others.  These are not all specifically ‘job tips’, but I believe there is certainly some value in reading these opinions as you decide on which directions you may take your software career.

The quotes below are ESR’s responses to questions, organized by topic.

ON PYTHON
“Yes, I really like Python.  I like it for a very specific reason.  I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability.  That is, the ease with which you can read your code six months later.  The longer I program, the more convinced I am that that is THE most important metric of a language, bar none… Most of the programming I do these days is in either Python or C.”

ON JAVA
“I still haven’t actually learned Java well enough to do more than a couple hundred lines of programming in it.  I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy.  So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’.

ON C++
“C++ has the exact opposite problem to the virtue I had called out in Python.  Long-term maintainability of C++ code, TERRIBLE.”

ON PERL (answer continues from his answer on C++ above)
“OK, the best thing I can say about that is, it’s not as bad as Perl, but I’m afraid that constitutes damning with faint praise.  I still like Perl fine and occasionally use it, as long as the program isn’t more than 25 lines long.”

ON GOOGLE GO
“I am sort of gingerly dipping my toes into the waters of Go, Google’s new language… I’ll tell you one concurrency thing I am really pleased by.  I have been wondering since about 1971 why nobody took the ball and ran with Hoare’s communicating sequential processes model.  So elegant, so pretty, so nice to reason about and 40 years later the Go people picked it up and ran with it.  That’s one reason I’m looking at Go.  CSP is the basis of their concurrency model in that language which is enough to motivate me to want to look at it some more.”

THOUGHTS ON THE JVM BECOMING MORE GENERAL PURPOSE
“I’m mostly ok with that.  I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be.”

ON RUBY 
“I’ve dipped into Ruby a little bit, there was a point where I had to modify some Ruby code for a project I was working on, so I think I understand the language a little, maybe not master level.  My impression of Ruby is that it has pretty much the same virtues and the same problems as Python, and I might be tempted to switch except that it’s not different enough.  Functionally speaking of course, I mean aesthetically there is all kinds of odd little differences.  But it’s not different enough from Python to make me move, that’s my impression.”

ON SCALA
“It’s on my list of languages to learn.  I have a friend whose judgment I trust who says it is a very good design, and that’s enough reason for me to go look at it.”

ON OPEN SOURCE LICENSING/GPL
“…this is one of my more incendiary opinions, I don’t think we need the GPL anymore…My attitude in general is just use permissive licenses, stop with the viral stuff…”

ON OPEN SOURCE 
“If you’re thinking in terms of bringing open source inside the corporation, you’ve already failed.  That is already thinking in the wrong direction because you’re trying to figure out how to control and make safe a process that thrives on lack of control and no safety, other than good code review.  Instead of thinking about how to bring open source inside the corporation, the right kind of question to ask is ‘how do I start up an open source project that benefits my corporation, build a community, and THEN sell it to my bosses?’.  Because one of the iron laws of dealing with bureaucracy is ‘it is easier to get forgiveness than permission’…How do I start an open source project that will interest my bosses, get it viable, and then sell it to them once they have a benefit that they can see?…Show them a benefit.  Don’t say ‘we can do this wonderful thing if you authorize me to spend n hours with no obvious physical return’.  That is something a manager is always going to say ‘no’ to.  What you have to do is show them a benefit.  It works much better, for example, to find an existing piece of open source software that is fairly close to solving the business problem and going to your boss and saying ‘you know, this thing already works and already has a user community and I can show you where it’s deployed, give me 50 hours and I can turn it into something that will solve our problem too’.  At that point you have a much better pitch, because that’s the kind of trade-off your manager is used to thinking about.”

ON OPEN SOURCING PRODUCTS DEVELOPED IN-HOUSE
“The universal argument that works for that is to say ‘hey boss, how would you like to reduce your maintenance costs?’.  Lay off the work on other people so it’s not coming out of your budget.  That’s the reason for open sourcing stuff that was developed in-house.  The argument for that is cost-spreading and risk-spreading.  And you want to put it exactly that way, ‘hey look, I’m going to reduce your bottom-line expenses’.”

PROS AND CONS OF CODING STANDARDS
“My first overarching observation is that the smartest thing you can do is choose a language in which coding standards are not necessary because there’s a uniform style that the language semi-enforces.  Yes I have Python in mind.  Go also has this property, it’s very difficult to have indent style variations in Go…The smartest thing you can do if all other things are equal is pick a language where you will never have coding standards wars.  The reason that that is a high-utility thing to do is, of course, the purpose of coding standards is to maximize readability of the code and long-term maintainability.  And yes, I do think that is extremely important… in particular if you are writing in C, the thing to do is pick a coding standard but don’t try and be too anal about it.  There comes a point at which the effort to enforce every conformance to every minutiae of a coding standard is causing you more pain and overhead than it is actually worth in reduced maintenance costs.”

THOUGHTS ON LISP/FUNCTIONAL PROGRAMMING
“There’s a can of worms.  The first thing you need to know about me in this connection is I’m an old Lisphead…I actually cut my teeth on APL…The result of the first two languages that I learned is I have this mental measure of a programming language’s adhesiveness.  A programming language is adhesive to the degree that it sticks to your brain and cannot be displaced from your brain except by a language that is more adhesive.  I learned APL first, and then I got exposed to Lisp…My first question was ‘which one is more powerful in a practical sense?’, and yes, yes I know they are all Turing equivalent…So I decided to test the question by writing two toy implementations.  One of an APL interpreter in Lisp, and one of a Lisp interpreter in APL…That is why I switched to Lisp, and discovered that Lisp is more adhesive than APL, and it displaced APL from my brain.  Nothing has displaced Lisp from my brain.  I have not encountered any language that is more adhesive than Lisp.  Which is not to say I use Lisp a whole lot, but that it still dominates the way I think about programming.”

ON HASKELL
“I dipped my toes into Haskell, and someday I’ll have to do a significant project in Haskell.  But that time is not yet though.  I haven’t found anything for which it is better than the tools I’m already using.  The problem with languages like Haskell…and I have digested dozens and dozens of computer languages in my time and I used to be a mathematician with a specialty in formal and foundational logic.  With all these credentials, Haskell makes my brain hurt.  So if Haskell and other pure functional programming languages make your brain hurt, that’s ok.  And the thing that worries me about them, is that if they make MY brain hurt, how the hell are they going to make any traction with people who didn’t used to be foundational logicians with a specialization in logic.”

ON FUNCTIONAL LANGUAGES
“My worry is that these are beautiful tools that will never actually achieve mass acceptance because they are simply too hard for most programmers to use.  The question is, what is the attraction then?  For the class of problems that is easily addressed using a functional language, using functional languages produces solutions that are breathtakingly, devastatingly elegant, beautiful and terse.  When the tool matches the problem, there are very few things in the universe more lovely than a properly designed functional program.  The issue though, is ‘A’ – that the tools are difficult to comprehend, and ‘B’ – I said ‘when the problem matches the tool’, there are lots of problems that don’t match functional programming language tools because functional programming language tools really want to live in a universe where everything is stateless and all transactions are reversible.  Uh oh.  You run into problems with those assumptions the moment you deal with messy things like input/output operations…intrinsically not reversible.  A lot of the complexity in functional programming languages arises from this unavoidable interface, this energy barrier between the programming language’s internal world of pure logic, statelessness and reversibility and infinite backtracking, and the messy exterior world where we actually have to deal with stateful objects…They are fascinating tools, they are good for some classes of problems, I love them aesthetically.  I don’t know if they will ever be more than a small minority preference.”

ON LEARNING FUNCTIONAL LANGUAGES
“Nevertheless, even though these tools may never get huge traction, learn one anyway.  When you get deep enough into any functional language, for me it happened with Lisp…there will come a point at which you will achieve Satori, you will achieve enlightenment about how functional programming actually works and your entire universe will lurch sideways and never be quite the same again.  And even if you never use a functional programming language for a line of code after that, it will change the way you think, it will change the way you form abstractions, it will clean things up.”

ON JAVA AND PYTHON SEEMING MORE FUNCTIONAL
“Ironically in the case of Python, Guido actually doesn’t like Lisp and his personal preference would be to take the functional constructs out of the language (Python), but every time he does that a bunch of his friends and senior developers, including me, look at him and say ‘you will take away my lambdas when you pry them from my cold dead fingers’.”

PYTHON VS JAVA 
“The advantage of Python over Java is that it’s less heavyweight, there isn’t a huge syntactic thicket of declarations and codicils and stuff that from a point of view of a Python programmer is extraneous junk that gets in the way of comprehension.  There are languages that are much worse that way, see my rant about C++.  Java is a bit too syntax-heavy and cluttered for optimum long-term maintainability.  That is my opinion anyway.”

OPEN SOURCE
“We now live in a situation where lots of people can use and enjoy open source tools and an increasing number of people can make a living writing and maintaining them, and that’s a good thing.  Do I want to see all software become non-proprietary?  It wouldn’t particularly bother me if that happened but it’s not a major objective for me.  It doesn’t harm me that other people write proprietary software as long as they don’t try to infringe on my freedom to write software the way I want to.  That’s the freedom I’m concerned with protecting.  I want people who voluntarily choose to be part of the open source community to be able to continue to be a part of it, and as long that objective is achieved, what other people do is not really of much concern to me.”

Your comments are welcomed below, thanks for reading.

Letter to ’12 Grads – How to Pick a Job and a Mentor

Cue ‘Pomp and Circumstance’ – hit play below to enhance the reading experience (or don’t, it’s just a song)

Dear Graduating Senior and Future Technologist,

First, congratulations on earning your degree! A degree is generally considered as a ‘nice to have’ and not a firm requirement for most programmer slots these days, and hopefully you learned quite a bit about software development in your classes. Having that parchment could be an advantage over other candidates entering the competition for technology sector jobs.

Based on conversations I’ve had with other recent graduates, it seems you have probably received some bad advice and misinformation recently from professors, career placement advisers, your peers, and even your parents regarding your new search for employment. I certainly mean no disrespect to those trying to help guide you, but it is important that you also get some input from people ‘on the front lines‘ in the field. Some academics tend to be insulated from what is really happening in the software industry, and your parents may think that a good pension plan is what you should really be after.

First I will outline how your job search (as an entry level technologist) is unique and much of the generic material that you have read re: job searches will not be applicable. Then we will analyze how to best choose your job, and what to do when you start.

GETTING YOUR FIRST JOB OFFERS

There are quite a few things to keep in mind when trying to get your first job offer(s). I assume by now you’ve read a considerable amount of information on interview techniques and resume tips. Most interview prep info is applicable across the board for all experience levels. Regarding resumes, the first thing to keep in mind is that in most cases the value of your education > job experience, so details on your school projects and classwork should be highlighted and placed prominently on your resume. I don’t recommend an ‘objective’ section for experienced candidates, but for recent grads it is a good tool for conveying your drive and desire.

Companies are going to view many resumes and conduct several interviews with entry-level candidates. Hiring managers are well aware that a significant majority of new engineers will not be immediately productive upon hire. The decision to hire an entry level candidate is essentially an investment for the firm, where said investment has little current value (low productivity) but should hopefully reap dividends in the long-term. A company’s interview process becomes due diligence to weigh the risk and reward for any individual.

Why should someone hire you?
What makes you a better investment than your classmate?

The most important attributes for entry-level engineering hires are:

  1. Willingness to do whatever is asked, and some things that are not explicitly asked – The tasks given to an entry level engineer will generally be the least interesting, so you will need to pay some dues. Remember Ralph Macchio waxing cars and painting fences in The Karate Kid? (Oh, class of 2012, almost forgot – did Will Smith’s kid wax cars in the remake?) For the first few months of the job, you will be Ralph Macchio – go buy a headband. Sure, Ralph got a bit lippy with Miyagi from time to time, but he finished the jobs and learned his craft. Convey in your resume and during interviews that you are a team player and willing to do what is necessary to further the goals of the company. Bonus points if you can show initiative (I recently had a candidate that was given the task of writing a small application at home as part of the interview process, and she decided to write a test suite and readme file that were not part of the assignment – brilliant!).
  2. Desire and ability to learn – The desire to learn will be an intangible that may be best demonstrated by any extracurricular engineering-related activities that you do. School tech clubs, user groups, hobbies, and conferences all apply to your curiosity. Ability to learn might be shown via an anecdote about a school project where you had to pick up a new tool or language with little guidance to complete the task.
  3. Youthful exuberance and enthusiasm – Injecting young talent into an organization can give a spark to any disillusioned engineers who may be losing passion. Someone with great positive energy (even combined with limited skills) has great value as a catalyst. In sports, these are players that may be referred to as ‘good locker room guys’. Don’t do cartwheels in your interview, but showing managers a contagious energy that people can feed off is a real benefit that you could provide immediately while learning the trade.
  4. Malleability – One good thing about not having any job experience is that you should be somewhat free of any bad habits. When given a choice between entry level and someone with just a bit more experience that has some potential baggage, companies will most often take the blank slate. The team will help mold you into being productive specifically within their environment and development methodology. It’s difficult to demonstrate malleability in interviews, but be willing to let it happen.

CHOOSING YOUR FIRST JOB AND WHAT TO DO WHEN YOU START

It seems that many of you were recently told how vitally important your first job is and to be extremely selective in making a choice, and I agree that your first job in the industry can be significant. However, it is probably not quite as important as you think, and based on many conversations it is not nearly as significant as you are being told. You are entering a field that is known for a high turnover rate with available statistics tending to fluctuate in the 10-25% range (often higher for first jobs), so odds are you won’t still be at this first job in a few years anyway. So let’s consider how to get the most out of the experience.

When I speak to entry-level and junior engineers and ask them about their job search criteria, I generally get similar answers to the ones I get from more experienced pros. “Interesting technologies and problem domains, challenging responsibilities, good people/culture, competitive compensation and benefits, stability…” Does knowing that the software engineering field has historically had a high turnover rate change any of your criteria?

“But my professor said I shouldn’t take a job using certain languages, my adviser said I should be paid at least $63,200 per year, and my parents told me I need to be looking for job stability.”

No, no, and no! The language is just a tool to use while learning the trade (noting that some tools/skills are more marketable than others), the money will come to you if you take the right steps in your career, and I hate to be the bearer of bad news, but there is no such thing as stability anymore. The first job search should not be about trying to get rich quick, nor should it necessarily be about finding an employer that you will be with forever.  Did you plan on marrying the first guy/girl you dated? If it happens, great, but let’s not go into this first search with unrealistic expectations. What is really important about your first job?

The single most important thing you should be looking for at the start of your career is to work in an environment where people are both able and willing to teach you how to become a better engineer.

Other factors will obviously come into play, but be sure to weigh those with the above in mind. Just because a software shop pays the highest salary, uses the newest technology, has plenty of customers, offers you the most job responsibility and passes the Joel Test doesn’t make it the best place for a freshly minted engineer (but it does sound pretty tempting).

Being ‘taught‘ doesn’t mean that you should seek out companies that provide formal training sessions in air-conditioned lecture halls, as that was what college should have been. It also doesn’t mean that you will be coddled and have your hand held every step of the way. Swimming lessons are taught in the pool for a reason, and the deep end can be more useful than the shallow end for certain training purposes.

Able to teach would be characterized as a team with strong developers (preferred size is debatable but somewhat irrelevant) and communicators that have good habits and a track-record of writing quality code. Ideally the team is busy and productive enough where new engineers can learn to function in a fast-paced environment with deadlines, but not so chaotic that the company doesn’t have the luxury of letting you make the occasional mistake. Aside – You are going to make mistakes, so be prepared to accept some blame for a problem you created, learn from the mistake, and don’t compound the problem by passing the buck.

Willing to teach can be a little complicated with both personalities and time constraints being potential inhibitors. You want need to find a mentor, and strong technologists will need to have their egos stroked a bit (protip – you will find a few egos in the tech world). The search for a mentor is not a race and shouldn’t be taken lightly.  Some may argue that finding the ‘right’ mentor could be as important as finding the ‘right employer.

Take a few weeks to try and figure out who the best engineers are in your team/department, and who you could learn the most from (note that the best engineer often does not equal the best mentor). Which developers are tasked to explain things to other team members and which ones conduct internal training activities? Once you have some ideas as to who the best engineers are, maybe try asking them a few test questions to see how responsive they are to helping out the newbie. Finally, choose the best fit based on all these factors and tell her/him that you are interested in being mentored.  If this person likes you she/he will most often be flattered, and hopefully you now have your first guide through your early career. If this person refuses or seems hesitant, go ask your second choice.  Repeat as necessary.

Once you’ve found your mentor, pay careful attention and try to figure out what makes this person such a good engineer. Note their work habits, interactions with both technical and business teams, reading materials/bookmarks, how they handle working under duress, etc. How does he/she respond to unrealistic deadlines, his/her own bugs, dissension within the ranks? Continue to ask questions and be conscious of any social cues your mentor might be sending out (i.e. learn to differentiate the ‘Not now, kid’ leer from the ‘You could just Google that question’ stare).

Now that you have a mentor, show your mentor your appreciation by both being grateful and working hard.  Don’t be the last one in or the first one out, as people notice those things for new hires. Your performance will now reflect somewhat on your mentor, so even if your actual contribution is somewhat low your effort should never be in question.

Remember that as an entry-level developer you are an investment for the company, and the harder and smarter you work the more apt you are to begin paying dividends. Don’t make them regret their decision to invest in you. Chances are you won’t be at this first job for more than a few years, so absorb as much information as you can from your the opportunity and your mentor.