Average Salary - Junior Developer

[Paul_S]

You can't expect to earn exponentially more if you sit in the same role for 10 years.

It depends on the company you work for.
I've been working at a company for 7 years and my salary increases were inflation related and I'm now earning a reasonable amount.
The problem I face now is that most companies pay far less than I'm currently being paid so when I move I may have to take a salary cut.
It looks like most companies pay senior system administrators/engineers between R25K and R30K per month (regardless of location, education and experience) which is a lot less than I'm currently earning.
Maybe it's time for me to look at another career path ...

 

[^^vampire^^]

I understood your point. My point is that you made it using the technical equivalent of the Power Rangers - you are way out of the ballpark in terms of understanding the realities of complex systems and the types of issues that a new hire faces in these environments. You're just guessing at the type of things that cause complexity for us - sure those sort of things happen, but that is very separate from the inherent complexity in the system.

Your contention that changing up jobs all the time is a good career decision and that a new hire in any situation can contribute to the core of any system within a few weeks or months, is what is making you look foolish. You simply don't have the experience to make these assertions, and seem to suffer from a flat earth delusion because of it.

Perhaps because the assumption I was working with was that of hiring an experience software developer that has a strong mind and picks up things easily. Yes some people can't contribute quickly and obviously they need to be assessed etc before they do contribute but what I'm saying is it is very few and far between that anyone will work on a system when such stringent rules and procedures need to be put in place. Also you run a high risk of the devs losing focus and will to contribute if they feel they are employed and not contributing to the environment.

 

[ToxicBunny]

Perhaps because the assumption I was working with was that of hiring an experience software developer that has a strong mind and picks up things easily. Yes some people can't contribute quickly and obviously they need to be assessed etc before they do contribute but what I'm saying is it is very few and far between that anyone will work on a system when such stringent rules and procedures need to be put in place. Also you run a high risk of the devs losing focus and will to contribute if they feel they are employed and not contributing to the environment.

You can be as sharp as you want, some companies systems are massively complicated, and yes it is spaghetti code etc etc.. but it CAN'T be re-written due to the monumental scale of the system.

And no you don't run a high risk of good devs losing focus, if they're aware of what they're walking in to, they relish the challenge that they're going to be given.

 

[cguy]

Perhaps because the assumption I was working with was that of hiring an experience software developer that has a strong mind and picks up things easily. Yes some people can't contribute quickly and obviously they need to be assessed etc before they do contribute but what I'm saying is it is very few and far between that anyone will work on a system when such stringent rules and procedures need to be put in place. Also you run a high risk of the devs losing focus and will to contribute if they feel they are employed and not contributing to the environment.

I never said anything about stringent rules and procedures, most people simply can't contribute immediately, because they don't have the requisite information and understanding of the system. This has nothing to do with with whether or not you are "hiring an experienced software developer that has a strong mind and picks up things easily" - the type of people we hire are the best and the brightest from across the world, some with decades of experience at top tech companies, some with PhDs from top schools, some with both, not to mention that they passed one of the most taxing interview processes around - they cannot just grok the system in a couple of months, and I promise you, neither can you. You're saying the equivalent of, "I went to Finland, and heard/read Finnish for the first time, and could I could understand it in 5 minutes" - no you just can't.

 

[Edwe]

I never said anything about stringent rules and procedures, most people simply can't contribute immediately, because they don't have the requisite information and understanding of the system. This has nothing to do with with whether or not you are "hiring an experienced software developer that has a strong mind and picks up things easily" - the type of people we hire are the best and the brightest from across the world, some with decades of experience at top tech companies, some with PhDs from top schools, some with both, not to mention that they passed one of the most taxing interview processes around - they cannot just grok the system in a couple of months, and I promise you, neither can you. You're saying the equivalent of, "I went to Finland, and heard/read Finnish for the first time, and could I could understand it in 5 minutes" - no you just can't.

I agree with this. Just my two cents: I think the two opposing sides here are talking about two completely different things. If you are hired to "simply code" and you have somebody with domain knowledge holding your hand and giving you exact specs, almost to the point of writing your unit tests for you, you should be able to be "productive" within a week or two. Some companies who work on excessively complex systems actually operate like this. This, IMHO, is not what I view as a developer role; this is just a coding monkey role.

if you are to work more or less independently in a project with a sufficiently large existing knowledge base, there is simply no way you can be really productive in the first few months. Heck, I can think of at least one project where you wouldn't even have time to READ through the knowledge base in 2 months, let alone understand most of it. Sure, you can start coding before you finish your domain ramp-up, but chances are you will be writing less effective code and you could have been more productive by focussing solely on ramp-up first.

Obviously this does not apply to 99% of projects, but that 1% definitely exists, whether you believe it or not.

 

[Kilgore_Trout_Redux]

So people who code according to specifications are just code monkeys.

That is some condescending and downright false bulls#!t right there. So companies who approach development in a reasonable and professional manner create inferior developers? If you expect a new developer to learn a domain by osmosis and don't provide support to learn a domain then you are shooting yourself in the face as well as the poor bastard you have just hired. You are also wasting bucketloads of your companies money.

If you don't know what you are coding and don't take time to design systems you will churn out buggy unstructured code that takes six months to wrap your head around for all the wrong reasons.

 

[cguy]

I agree with this. Just my two cents: I think the two opposing sides here are talking about two completely different things. If you are hired to "simply code" and you have somebody with domain knowledge holding your hand and giving you exact specs, almost to the point of writing your unit tests for you, you should be able to be "productive" within a week or two. Some companies who work on excessively complex systems actually operate like this. This, IMHO, is not what I view as a developer role; this is just a coding monkey role.

if you are to work more or less independently in a project with a sufficiently large existing knowledge base, there is simply no way you can be really productive in the first few months. Heck, I can think of at least one project where you wouldn't even have time to READ through the knowledge base in 2 months, let alone understand most of it. Sure, you can start coding before you finish your domain ramp-up, but chances are you will be writing less effective code and you could have been more productive by focussing solely on ramp-up first.

Obviously this does not apply to 99% of projects, but that 1% definitely exists, whether you believe it or not.

Yeah, but those 1% of projects are what 20% of developers work on.

I think you are just reiterating my point. I am not saying that all projects/jobs are like this, but just that if you job hop and only work at companies for 1-1.5 years as ^^vampire^^ suggests, you will never be more than an easily replaceable code monkey, because you will either never work on anything complex, or never contribute anything beyond the superficial.

 

[Kilgore_Trout_Redux]

Yeah, but those 1% of projects are what 20% of developers work on.

I think you are just reiterating my point. I am not saying that all projects/jobs are like this, but just that if you job hop and only work at companies for 1-1.5 years as ^^vampire^^ suggests, you will never be more than an easily replaceable code monkey, because you will either never work on anything complex, or never contribute anything beyond the superficial.

Given the 6 month figure given above to be comfortable in a domain it means 1 year of contributing to a company

Although as mentioned I prefer to spend 2-3 years at a company.

 

[cguy]

Given the 6 month figure given above to be comfortable in a domain it means 1 year of contributing to a company

Although as mentioned I prefer to spend 2-3 years at a company.

Nope. They won't hire some like that in the first place. Wasted training effort, lead time for replacement, operational risk, cost, etc.

 

[ToxicBunny]

Nope. They won't hire some like that in the first place. Wasted training effort, lead time for replacement, operational risk, cost, etc.

Yeah job hopping ever 1 to 1.5 years will seriously limit exposure to the larger stuff out there, because the companies just won't even look at hiring a person like that.

The job hopping is not necessarily a bad thing initially in a persons career, but as they get older there needs to be some semblance of stability, it will open doors to larger projects.

 

[^^vampire^^]

Yeah job hopping ever 1 to 1.5 years will seriously limit exposure to the larger stuff out there, because the companies just won't even look at hiring a person like that.

The job hopping is not necessarily a bad thing initially in a persons career, but as they get older there needs to be some semblance of stability, it will open doors to larger projects.

Anyway I think we got a bit off topic here. The topic was about salary and I would tend to agree with what you say above. In the unlikely circumstance that you wind up with a company with such an intricate system then yes I can see why you wouldn't want to hire a job hopper but we need to get real here, there are next to no companies offering people what they are worth in this country and hence why people job hop (yes there are exceptions).

I'm all for fighting your case on why you deserve to earn x or y but 99% of companies/recruiters say they won't offer more than a 20% increase - which is ridiculous since they say that before they've interviewed you. Companies not having funds to offer what you are asking is understandable but when they haven't even tested you and say they won't offer what you are asking for is a little ridiculous, especially when what you are asking for is within their specified range as advertised. This in my opinion is counter productive unless it's a guy with 1 year experience looking for a ridiculous amount but that should be blatantly obvious from the get go.

Anyway, because of this stance of companies not willing to judge and reward a candidate properly the only other option is to job hop until you are comfortable with you salary and then you can settle in for the long term, as it is in my case. If you can find a company that is converse to this then great.

Also there are other factors to take into account. For instance, I live on the Westrand and because of the horrible little roads from my house to the highway and all the clogged up backroads it makes it unfeasible for me to work in Sandton etc where it seems like all the higher paying jobs are. My friend who lives near me leaves at 5am in the morning to get to Sandton otherwise he sits for 2.5 hours in the traffic. I'm not really keen to swap my 12 min commute for either leaving at 5am or sitting in traffic for 2.5 hours so I'm kind of stuck where I am.

 

[^^vampire^^]

I agree with this. Just my two cents: I think the two opposing sides here are talking about two completely different things. If you are hired to "simply code" and you have somebody with domain knowledge holding your hand and giving you exact specs, almost to the point of writing your unit tests for you, you should be able to be "productive" within a week or two. Some companies who work on excessively complex systems actually operate like this. This, IMHO, is not what I view as a developer role; this is just a coding monkey role.

if you are to work more or less independently in a project with a sufficiently large existing knowledge base, there is simply no way you can be really productive in the first few months. Heck, I can think of at least one project where you wouldn't even have time to READ through the knowledge base in 2 months, let alone understand most of it. Sure, you can start coding before you finish your domain ramp-up, but chances are you will be writing less effective code and you could have been more productive by focussing solely on ramp-up first.

Obviously this does not apply to 99% of projects, but that 1% definitely exists, whether you believe it or not.

So while you as a developer are reinventing the wheel for the 15th time some code monkey is inventing ABS, EBD etc etc

Wow, the amount of different things I wrote in reply to this before I just deleted it all...

 

[Edwe]

So people who code according to specifications are just code monkeys.

So while you as a developer are reinventing the wheel for the 15th time some code monkey is inventing ABS, EBD etc etc

Wow, the amount of different things I wrote in reply to this before I just deleted it all...

Not what I meant, but maybe I didn't state my meaning clearly. Let me clarify using an example:

Person A is a developer. She needs to develop an ABS prototype. As a software developer, she is able to break down the user specification into constituent elements, specify each formally, and code a solution. If not the whole solution, she is at least able to understand, in a general sense, the system, or a functional unit thereof, as a whole.

Person B is a coding monkey. She does not understand the purpose or complete working of the system or any functional unit thereof, and she is not expected to be able to. She merely receives and implements small bits of unrelated system specs, such as, "write a function which takes as parameter sensor inputs ranging between integers in 0-255 inclusive, and maps these linearly to real values in 0.0-0.5". She does not know why this function needs to exist, nor its purpose in the larger system.

The main difference being that a developer understands why, in a functional sense, they are doing what they are doing beyond "in order for the test my boss wrote to pass".

Yeah, but those 1% of projects are what 20% of developers work on.

I think you are just reiterating my point. I am not saying that all projects/jobs are like this, but just that if you job hop and only work at companies for 1-1.5 years as ^^vampire^^ suggests, you will never be more than an easily replaceable code monkey, because you will either never work on anything complex, or never contribute anything beyond the superficial.

My intention was to reiterate/support your point.

 

[Edwe]

So while you as a developer are reinventing the wheel for the 15th time some code monkey is inventing ABS, EBD etc etc

Wow, the amount of different things I wrote in reply to this before I just deleted it all...

Just out of curiosity, which part of what I said leads you to believe that what I said, i.e. that ramping up on domain knowledge before starting work, would cause devs to reinvent existing technology? I would think that proper research would lead to exactly the opposite, because you would be more likely to know about existing solutions.

 

[Kilgore_Trout_Redux]

Person A is a developer. She needs to develop an ABS prototype. As a software developer, she is able to break down the user specification into constituent elements, specify each formally, and code a solution. If not the whole solution, she is at least able to understand, in a general sense, the system, or a functional unit thereof, as a whole.

Person B is a coding monkey. She does not understand the purpose or complete working of the system or any functional unit thereof, and she is not expected to be able to. She merely receives and implements small bits of unrelated system specs, such as, "write a function which takes as parameter sensor inputs ranging between integers in 0-255 inclusive, and maps these linearly to real values in 0.0-0.5". She does not know why this function needs to exist, nor its purpose in the larger system.

The main difference being that a developer understands why, in a functional sense, they are doing what they are doing beyond "in order for the test my boss wrote to pass".

The issue with me is that people are frequently A&B at the same time when they start at a company.

Person B can use the detailed spec to learn the specific control in depth and its general place in the system. A good specification and explanation means that they now understand that part of the domain and how it interfaces with the related components.

They have made immediate inroads into the system and can now maintain a part of it and understand its place within a larger more general system.

This is how sane people learn complex systems.

They have added value and learned part of the domain (Not all of it.) without being at the company for 6 months. If you recall the original argument - you cannot make a positive contribution for 6 months.

 

[Edwe]

The issue with me is that people are frequently A&B at the same time when they start at a company.

Person B can use the detailed spec to learn the specific control in depth and its general place in the system. A good specification and explanation means that they now understand that part of the domain and how it interfaces with the related components.

They have made immediate inroads into the system and can now maintain a part of it and understand its place within a larger more general system.

This is how sane people learn complex systems.

They have added value and learned part of the domain (Not all of it.) without being at the company for 6 months. If you recall the original argument - you cannot make a positive contribution for 6 months.

Note that I said

Person B is a coding monkey. She does not understand the purpose or complete working of the system or any functional unit thereof, and she is not expected to be able to.

I agree that the exact same technique (combination of A&B), combined with mentoring and self-study of the relevant material, is part of a sane learning process. In contrast to this, there are some companies that are perfectly content to leave their programmers as pure case B (especially companies that outsource to sweat shops and don't want to expose too much of their IP).

In the former, sane, case, the developer's "productive" work during the first few weeks or months is typically negated by non-negligible, otherwise billable hours spent by more senior mentors in assisting with on-boarding and ramp-up. The new dev may, when viewed in isolation, do (for the sake of the argument) 20 days of billable work in the first 2 months, but her mentors have probably lost about a cost-equivalent number of hours in the process. The nett effect, in terms of absolute billable hours, is basically zero. I am not saying that the effort has been lost - on the contrary, upskilling is a vital aspect of growth in most companies - I am just saying the dev will probably not be productive in an absolute, billable sense.

 

[Kilgore_Trout_Redux]

The new dev may, when viewed in isolation, do (for the sake of the argument) 20 days of billable work in the first 2 months, but her mentors have probably lost about a cost-equivalent number of hours in the process. The nett effect, in terms of absolute billable hours, is basically zero. I am not saying that the effort has been lost - on the contrary, upskilling is a vital aspect of growth in most companies - I am just saying the dev will probably not be productive in an absolute, billable sense.

Fair point.