Where are all the skilled developers?

@zippy, its not merely for my CV. I love working in Java, took this job with a pay cut just because they worked on a Java based stack. Ultimately got to do just JSF, Primefaces, HTML and CSS. No exposure to any back-end systems. I spend days sometimes weeks doing nothing bar the odd website update. I want to learn and get exposure to other technologies.
 
@zippy, its not merely for my CV. I love working in Java, took this job with a pay cut just because they worked on a Java based stack. Ultimately got to do just JSF, Primefaces, HTML and CSS. No exposure to any back-end systems. I spend days sometimes weeks doing nothing bar the odd website update. I want to learn and get exposure to other technologies.

Ahh I see, there is an amazing site that has all of that for free, you just need some motivation :)
 
Pair programming is an interesting topic. Personally I don't think it is a great concept at all (dons flame suit). One of two things happen: you either pair two "weak" personalities developers and the work rate drops even more or your pair a strong with a week and frustrate the crap out of the stronger guy. And a frustrated developer is somebody looking for greener pastures. (OK, I generalise but you need the right personalities as mentors).

Companies (and senior devs) are very guilty in not providing thorough training to juniors. Nobody wants to be slowed down by a junior hence the whole "sink or swim" thing. It is unfair towards you guys and we should make an effort to put procedures/team structures in place to aid and grow you.

If you are stuck in html and css, ask (no, pest) your superiors to give you more challenging work and then do whatever you need to do to get it done (even if it means working weekends). If they ignore your requests it might be time to look for somebody who will.

As for the crap pay - deal with it. You'll earn more soon enough.

NOTE: I know that Driven Software is big on pair programming, SOLID and all the other acronyms, so if this is what you are looking for maybe send them your CV. They also do a lot of "training sessions" called code retreats all over RSA. I can put you in contact with one of the organisers if you want to attend one.

Interesting response. Agree on the part that productivity goes through a slump during pair-programming but depending on the junior dev, it can go back up once he has been up-skilled enough.
The sink-or-swim thing works well sometimes and I remember pleading with my seniors to give me bigger projects. Got a break when the senior dev I was working under disappeared for 3 days and I was the only one who know how he had built the reports and reporting packages. Some good junior devs move to sales rather then tough-it out and become PM's.
 
I don't see why, as a senior dev, I should be training a junior dev. I'm not a trainer. If I wanted to train people then I would look for a job as a trainer. Happy to mentor every now and then. But training? Forget it. I'll go work somewhere else. :)
 
I don't see why, as a senior dev, I should be training a junior dev. I'm not a trainer. If I wanted to train people then I would look for a job as a trainer. Happy to mentor every now and then. But training? Forget it. I'll go work somewhere else. :)

Skilling up a junior takes time true but it and isn't your everyday job. If said junior has an issue, instead of wasting 8+ hours looking for a solution by himself, wouldn't you prefer it if after 1 hour odd if he gets no joy he asks you for assistance on the correct way to be going about something? Doesn't helping someone improve doesn't give you the warm and fuzzies?

/remembers to send thank you note to all the seniors and mentors that have helped me along.
 
I don't see why, as a senior dev, I should be training a junior dev. I'm not a trainer. If I wanted to train people then I would look for a job as a trainer. Happy to mentor every now and then. But training? Forget it. I'll go work somewhere else. :)

With this sentiment you will always be stuck in the position you are in. I think there is nothing wrong with taking in juniors and providing them on-the-job training. For me mentoring and training is the same - i.e. it's on-the-job training where juniors get challenging tasks and seniors and peers mentor/peer-review and train them. Auxiliary to the on-the-job training should be the requirement to do formal certifications/training (i.e. linux guys finish LPIC / Java guys follow the Java certs).

I nowadays prefer juniors over seniors purely from the aspect that you can guide juniors to work in a specific way and it works out better than employing overpaid seniors. Obviously you do require more supervision and training and coaching but after a few months it pays off. I can employ 3 juniors for the price of one senior resource and productivity will level within 6 months. Benefit for the juniors is rapid skills development and quick acceleration of salary. This works very well for people who have the appetite to learn, grow and be constantly challenged.

TBH - out of a pool of 100 senior Java CVs received only 3 (!) people could answer senior-level Java questions. The rest could not code themselves out of a wet paper-bag and failed the practical tests (i.e. look at a Java class and identify the problem areas). Makes one think what the quality of work is and I think my personal experience in looking for Java- and Linux people allows me to say that most people marketing themselves as "Senior XXX" are actually only senior because of their payslip and not actual skill or knowledge.
 
With this sentiment you will always be stuck in the position you are in. I think there is nothing wrong with taking in juniors and providing them on-the-job training. For me mentoring and training is the same - i.e. it's on-the-job training where juniors get challenging tasks and seniors and peers mentor/peer-review and train them. Auxiliary to the on-the-job training should be the requirement to do formal certifications/training (i.e. linux guys finish LPIC / Java guys follow the Java certs).

While I don't think there is anything wrong with on the job training, I don't see why it should require a significant time investment by senior dev's. I often mentor new hires - which usually means an hour long presentation, a half an hour code walk through, and after that they're pretty much on their own. Asking questions is fine as long as a reasonable effort has been made to answer it themselves. The rest of the learning comes from reading and running code, and the various bits of intranet documentation and slides we have. Also at all the places I've worked, when someone is hired, there is no need for formal training/certification - why would we hire someone who couldn't easily teach themselves the details of Linux development or Java?

I nowadays prefer juniors over seniors purely from the aspect that you can guide juniors to work in a specific way and it works out better than employing overpaid seniors. Obviously you do require more supervision and training and coaching but after a few months it pays off. I can employ 3 juniors for the price of one senior resource and productivity will level within 6 months. Benefit for the juniors is rapid skills development and quick acceleration of salary. This works very well for people who have the appetite to learn, grow and be constantly challenged.

This often makes a lot of sense, but it really depends on the sophistication and complexity of the work they are being required to do. If junior hires can reach the same level of productivity in 6 months, the work being done is likely fairly simple. I'm not disagreeing with you or anything, just pointing out that your experiences aren't necessarily typical.

TBH - out of a pool of 100 senior Java CVs received only 3 (!) people could answer senior-level Java questions. The rest could not code themselves out of a wet paper-bag and failed the practical tests (i.e. look at a Java class and identify the problem areas). Makes one think what the quality of work is and I think my personal experience in looking for Java- and Linux people allows me to say that most people marketing themselves as "Senior XXX" are actually only senior because of their payslip and not actual skill or knowledge.

Sure, but the "CVs received" has a huge selection bias (towards ineffectual developers). This is why people go to head hunters: to find the competent, and likely happily employed good senior developers out there. Otherwise you'll land up looking for a needle in a haystack.
 
Last edited:
Also at all the places I've worked, when someone is hired, there is no need for formal training/certification - why would we hire someone who couldn't easily teach themselves the details of Linux development or Java?
You want to provide your staff with marketable skills. While I hope that none of my people will ever leave the company, you should expect some attrition (change in lifestyle or interest) and as such as a company should assist staff in further education. People hardly ever move for money - in most cases it's job-satisfaction, work-environment, learning something new (all originating from perhaps a stagnant, uninteresting job). In many cases juniors will be "groomed" for maintenance work and never get to touch anything interesting or risky.

If junior hires can reach the same level of productivity in 6 months, the work being done is likely fairly simple. I'm not disagreeing with you or anything, just pointing out that your experiences aren't necessarily typical.
Perhaps I have been lucky, but in our case the complexity of work is quite complex (as any real-time transactional system would be) and in most cases I throw juniors into the deep end (obviously with mentoring) and although the journey is a bit rocky (due to understandable inexperience of the juniors) in the end they will have gained a vast amount of knowledge (and sense of accomplishment).

Sure, but the "CVs received" has a huge selection bias (towards ineffectual developers). This is why people go to head hunters: to find the competent, and likely happily employed good senior developers out there. Otherwise you'll land up looking for a needle in a haystack.
In more than a decade in the industry I have seen it all. During my FNB days I went through close to 500 CVs (all from agencies and headhunters) and eventually picked 3 capable staff (where skill, personality and pay aligned). In most cases you will find that skill/personalty/pay show a discrepancy (i.e. candidate his highly skilled and highly paid, but his personality will not fit into company culture). Also headhunting people is tough - those are the guys you really want, but since they are happy with salary and work-environment, it is tough to convince them to join you (unless they have a personal reason - such as closer to home, less hours etc).
 
@zippy, you seem to think like my manager. No skills development, no training, no career plan within the company. This is what makes junior leave in a few months. I guess your ego is too big to bother with juniors.
 
@zippy, you seem to think like my manager. No skills development, no training, no career plan within the company. This is what makes junior leave in a few months. I guess your ego is too big to bother with juniors.

And to all the juniors looking for something exciting - have a look at robots.txt and send your CV ;-)
 
@MagicDude4Eva, its not always about excitement. One needs to have a goal and sense of purpose in life. Pointless sitting for weeks with nothing todo all day bcoz simple are not willing to let you use the available resources. At some point as a junior you need a senior person to guide you. No saying to be spoon fed, just some guidance. After all your youth are your best years for learning. I do not mind taking a pay cut just to be upskilled, as it will be worth it in the long term.
 
@MagicDude4Eva, its not always about excitement. One needs to have a goal and sense of purpose in life. Pointless sitting for weeks with nothing todo all day bcoz simple are not willing to let you use the available resources. At some point as a junior you need a senior person to guide you. No saying to be spoon fed, just some guidance. After all your youth are your best years for learning. I do not mind taking a pay cut just to be upskilled, as it will be worth it in the long term.

Agreed. I think if you are in a job and can not determine that you have made a significant difference in someone's life as part of the work you do, you should re-evaluate your involvement. Unfortunately in most big corporates you will always remain a tiny cog in the corporate machine. When I started off in IT (the good old C++, assembler, OS/2 days) it felt extremely gratifying to know that I was one of the few developers rolling out our application to 600 SBSA branches and knowing that the application was used by a few thousand staff for more than a decade. Most people nowadays take a job just as that - a source of income or a transitionary phase for that next salary jump - burning a lot of time without much real purpose.

Your seniors and managers should share the knowledge they have gained and it should really be their goal to be replaced by their subordinates - then you know that as a senior or manager you have done a good job.
 
I don't see why, as a senior dev, I should be training a junior dev. I'm not a trainer. If I wanted to train people then I would look for a job as a trainer. Happy to mentor every now and then. But training? Forget it. I'll go work somewhere else. :)

I certainly don't believe this is the right attitude. No one is saying do 24/7 hands on training. But at least provide guidance . This isn't to say give the junior guy all the answers. Rather, push him in the right direction. Trust me, he/she will learn a crap load more that way and more importantly understand where they went wrong and why things did not work. The key is understanding. Without that fundamental knowledge, you get a copy & past dev.

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

I would rather have a dev on my team asking me for help, getting to the answer quicker, rather than spending 2 days on it, when it could have been done in a day. More importantly having the dev grow and learn. It's a win - win situation. Productivity increases, knowledge grows.

Personally, if I was helping a dev learn and grow, by my own experiences, that to me is very satisfying. You know... making a difference in life. Changing people's lives for the better.

But if you're one of those grumpy devs' that your juniors fear or don't want to ask you any questions in case they get some snotty answer back.. meh, I doubt you will ever be anything more than a grumpy, dev. (I left out senior, there, as I believe its a senior's job to guide, help and grow juniors. )
 
This isn't to say give the junior guy all the answers. Rather, push him in the right direction. Trust me, he/she will learn a crap load more that way and more importantly understand where they went wrong and why things did not work. The key is understanding. Without that fundamental knowledge, you get a copy & past dev.

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

+1 for "copy & past dev". That is pretty much what I am working with. Spend more time fixing copy and paste errors made by someone else and regurgitating the same code with minor adjustments. Some people might think well be grateful you have a job, but with a degree and student loan to pay I have to consider the long term consequences.
 
Aah. I see zippy is sprouting the usual pile of trash he does. I don't think I've even found one decent post by him in any thread on this forum. Ever.
 
I certainly don't believe this is the right attitude. No one is saying do 24/7 hands on training. But at least provide guidance . This isn't to say give the junior guy all the answers. Rather, push him in the right direction. Trust me, he/she will learn a crap load more that way and more importantly understand where they went wrong and why things did not work. The key is understanding. Without that fundamental knowledge, you get a copy & past dev.

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

I would rather have a dev on my team asking me for help, getting to the answer quicker, rather than spending 2 days on it, when it could have been done in a day. More importantly having the dev grow and learn. It's a win - win situation. Productivity increases, knowledge grows.

Personally, if I was helping a dev learn and grow, by my own experiences, that to me is very satisfying. You know... making a difference in life. Changing people's lives for the better.

But if you're one of those grumpy devs' that your juniors fear or don't want to ask you any questions in case they get some snotty answer back.. meh, I doubt you will ever be anything more than a grumpy, dev. (I left out senior, there, as I believe its a senior's job to guide, help and grow juniors. )

I said I don't have a problem mentoring. Of course help, guide etc. When junior devs ask me something, I help them.

What I am saying is that I am not a trainer. I'm not prepared to stand in front of a group of people and teach them how to code. That's what training depts are for and what external trainers do.
 
Top
Sign up to the MyBroadband newsletter
X