Ask HN: How do you define a junior developer?
41–50 of 68 posts
Re: Ask HN: How do you define a junior developer?
#42They follow all the rules they were taught in school, like 'never ever use goto in C', until their first code review by a senior developer, who shows them that 'goto err' is much easier to understand than writing your cleanup block before every single return statement.
Re: Ask HN: How do you define a junior developer?
#43Senior developer: can use a computer to solve business problems.
Re: Ask HN: How do you define a junior developer?
#44Earlier quoted context omitted.
* Senior developer - Will produce immediate business value _only_ if completely ignored.
I have to disagree with this; a senior developer will produce more value if not completely ignored; if involved with the company, they can then not only help steer the technological direction of the company, but also move tech towards the company's future goals, not the company's current state. If left undirected, they will still move tech and be productive, but not necessarily in the direction the company wants to g…
Re: Ask HN: How do you define a junior developer?
#45The junior developer is blown around by every wind of shiny they know about. They want to build an infinitely flexible framework for everything, even if it's only being done once in your codebase. They follow all the rules they were taught in school, like 'never ever use goto in C', until their first code review by a senior developer, who shows them that 'goto err' is much easier to understand than writing your clean…
Re: Ask HN: How do you define a junior developer?
#46Earlier quoted context omitted.
I don't see looking for quick and easy wins is not a negative, nor is in opposition to understanding trade-offs.
Notice I didn't say "Negative -> Positive". It says "Junior -> Senior". Thinking about it further, I don't think it's possible to properly get to the second state (tradeoff-understanding) without going through the first (win-seeking) at some point in your career... in fact, when I'm hiring Junior devs I select for win-seeking behavior. "Tradeoff-understanding" is more of a philosophical disposition that one (IMHO the…
In the end, you're making a smart vs. wise distinction, and the two are neither independent nor opposed.
Perhaps fixes the problem in front of them vs. thinks about the problem in context (with the context getting bigger and hairier with more experience).
Re: Ask HN: How do you define a junior developer?
#47Instead of spending one second fretting about the exact useless definition of "junior", take a look at the candidate, their background, aptitudes and aspirations, their personality, your team, what the job actually requires, what you're willing to pay, and also what responsibility your org is willing to take on to train next-generation professionals. If you do that, it won't matter what "junior or senior or level X" means. The goal is to fit the right person to the right job.
Re: Ask HN: How do you define a junior developer?
#48It depends on when and why I'm defining it, but my guidelines are more based on how they work than what they know: * Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision. * Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals. * Senior develope…
This is what people here like to believe. But I don't think it is really true. A kid straight out of college can generate immediate business value if he/she can set up an online shopping cart in Php to give a business an online presence. I am pretty sure that the same kid can code up any business requirement of most of the local organisations that does not need to scale much or work with great reliability.
Also, it is not true that a junior dev requires supervision. Anyone with sufficient motivation and an internet connection can figure stuff out by themselves. I mean, they can get things done, even if in a fantastically stupid fashion.
Re: Ask HN: How do you define a junior developer?
#49"Do you have ten years of experience, or do you have one year of experience ten times?" A junior programmer is someone who has never learned from a serious mistake they've made while programming professionally. A junior programmer is someone who thinks they should be senior thanks to the Dunning-Kruger Effect ("Hey, I was an honors student at this great college!"). A junior programmer is someone who can't usefully me…
Nothing fixes this type of junior engineer faster than giving them some real responsibility. Let them fail then learn from it. Don't hold them back because that just builds up resentment.
So junior engineers aren't given responsibility, because they might break something.
I was lucky. The first time I was given real responsibility, I broke something badly (which turned out to be an actual OS bug, but that's another story). It was a learning experience - in large part, because I had to learn why things broke in production, but not in development. That lesson sticks with me to this day, 20+ years later.
Re: Ask HN: How do you define a junior developer?
#50The junior developer is blown around by every wind of shiny they know about. They want to build an infinitely flexible framework for everything, even if it's only being done once in your codebase. They follow all the rules they were taught in school, like 'never ever use goto in C', until their first code review by a senior developer, who shows them that 'goto err' is much easier to understand than writing your clean…
I hope I'm gonna stay Junior longer! I don't want to start using goto...
int
insane()
{
FILE *a = open("a", "r");
if (!a) {
return -1;
}
FILE *b = open("b", "r");
if (!b) {
fclose(a);
return -1;
}
FILE *c = open("c", "r");
if (!c) {
fclose(a);
fclose(b);
return -1;
}
int rv = (do something with a, b, and c);
fclose(a);
fclose(b);
fclose(c);
return rv;
}
Now here's an example where you only need to maintain one copy of your cleanup code: int
reasonable()
{
FILE *a = NULL;
FILE *b = NULL;
FILE *c = NULL;
int rv = -1;
a = open("a", "r");
if (!a) { goto out; }
b = open("b", "r");
if (!b) { goto out; }
c = open("c", "r");
if (!c) { goto out; }
rv = (do something with a, b, and c);
out:
if (a) { fclose(a); }
if (b) { fclose(b); }
if (c) { fclose(c); }
return rv;
}
Avoiding goto gets impossible the second you start doing socket twiddling, or message generation. Yes, languages with context managers (Python's with blocks), RAII (C++ or Rust), or defer (Go) make this easier, but some of us are stuck writing C sometimes.