This blog is inspired / provoked by recent article from Code for a living: "Why developers should always be in job-seeking mode" - that's why it makes sense to start there, if you didn't read it already. Btw. it's a decent blog in general, recommended.
I'm not going to repeat the content of the article mentioned - in general you can assume that I agree with what they claim. But I think that the reality is not as simple as the one depicted there - this blog post is meant to add some more thoughts "on the top".
Too eager to hop
Main thesis doesn't change - as a software development professional you should be ready for new job opportunities all the time. But it doesn't mean that you should "hop" jobs each time someone proposes you better financial conditions / there's a new technology at stake / first inconveniences appear in your current job.
It's very important to remember that your growing value in the job market isn't really based (regardless of what some clueless head-hunters think ...) on sheer number of years of professional experience ("3 years of Ruby on Rails programming") - what really counts is meaningful real-life experience. Figuratively speaking: gained in the real, battle-sooted trenches, not just dry-runs in the boy-scout camp ...
- full end-to-end software delivery life-cycle experience
- facing the consequences of own technical decisions kind of experience
- practical verification of architectural -ilities in the heat of battle (maintainability, operability, scalability, etc.)
Holistic perspective on software delivery is strikingly similar to low-level code work in this aspect: so-called happy path is not representative for what you'll encounter in real life. Your potential employers don't really care much about yourself being familiar with "tutorialesque" bookish knowledge about the bare syntax & "hello world". Such knowledge doesn't prove you being able to truly delivery anything of reasonable quality.
Pain? Pain is good ...
That's why real experience of real problems in factual scenarios is what really matters - in many, many cases these are painful, unpleasant situations that require much effort, energy & cause plenty of stress, but in fact it is the way we LEARN how stuff REALLY works.
Unfortunately there are many developers who are interested only in "happy path" - their preferred work environment are long-lasting, corporate, waterfallish projects, where ...
- they can collaborate on building something new from scratch, testing some new ideas w/o any burden of maintenance in the brownfield (hence no real feedback ...)
- ... and leave once "interesting work is over" & there's time for lengthy hardening, large-scale integration, user acceptance tests or just maintenance & development on the top of consequences of their own past decisions ...
Some could say that it's not a bad way to build quite a good looking CV: 1 year here, 2 years here, ..., renown companies, catchy technologies - everything seems to be in order. Due to all the reasons mentioned above, I dare to disagree.
When (not) to swap?
Fortunately swap / not swap criteria are not really a rocket science. There's a bunch of questions you should ask & honestly answer yourself. Pretty much the same set of questions applies to both current & prospect employers (which may create a challenge in the latter case ...).
Shrug? Shrug!
But before we get there - contrary to the common beliefs these are should NOT be the decisive factors:
- Is X the company that offers the biggest pay?
- Is X the big, worldwide, well recognised brand (like Fortune 500 or something)?
- Does this organisation use the most catchy method / tool / approach nowadays?
Cash shouldn't really matter that much (at least for the differences up to 25-30%) - I mean, you should value yourself reasonable, but let's be frank - even a junior developer should have no problems with making ends meet, w/o going for the highest paid offer. There are some things far more important than short term bonanza - if you make proper decisions, truly decent money will follow sooner than you think.
As regards the last question - methods, tools or approaches are far less important than actual people behind them: their way of thinking, mutual respect, eagerness for cooperation & overall openness. I've seen terribly broken Scrums, dramatically poorly applied bleeding edge technologies, but OTOH I've also experienced razor-sharp classic waterfalls or impressive utilisation of 10+ years old technology to provide unprecedented business effects.
That's why your network (of social connections) is your greatest weapon in the job market - knowing people you'll work with (or at least knowing people who've worked with them) is a great help in making a correct decision.
Attention, attention!
Ok, what DOES count then?
- Is there a person in X you will be able to learn from? Mentor, tutor, teacher, coach or even jedi master - someone who'll help you develop yourself (on the daily basis) in a formal or informal way.
- Does this company have a clear product vision, strategy (around the product), ownership (over the product)? In other words - are you / will you be contributing to something that really matters for the organization? Or is it rather a "shitty necessity" or a political decision kind of work?
- Do you really see a viable space for you in particular to grow in this organization? In a long-term perspective? In something that has potential to bring value to the organization & its clients, stakeholders, etc.
- And quite likely the most important (in addition - usually the hardest to answer as well ...) question - is X's company culture subordinate to actual delivery of value (focus on meaningful results) or is it a company that values politicking, internal games & eternal struggle for influence higher?
Pic: © nito - Fotolia.com
