Junior vs senior developers: what's the difference, anyway?
-
-
From personal experience - knowing: 1. what Visual Studio is and how to use it 2. how to debug code 3. how to write code that is testable through a test fixture 4. wait, even before #3, the concept that you have to test your code (true story) 5. how to tease apart requirements into an architecture that abstracts where things need to be abstracted, etc. 6. how to write a specification so someone can write the code for it 7. oh wait, before #6, how to write/communicate. (I got hammered as a kid for using "it" and "that", a lesson I took to heart many moons ago) 8. etc.etc.etc. But ultimately, the true difference between a junior and a senior developer is: The ability to say, and the frequent use of, the word NO Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
From personal experience - knowing: 1. what Visual Studio is and how to use it 2. how to debug code 3. how to write code that is testable through a test fixture 4. wait, even before #3, the concept that you have to test your code (true story) 5. how to tease apart requirements into an architecture that abstracts where things need to be abstracted, etc. 6. how to write a specification so someone can write the code for it 7. oh wait, before #6, how to write/communicate. (I got hammered as a kid for using "it" and "that", a lesson I took to heart many moons ago) 8. etc.etc.etc. But ultimately, the true difference between a junior and a senior developer is: The ability to say, and the frequent use of, the word NO Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Marc Clifton wrote:
The ability to say, and the frequent use of, the word NO
If you use the word NO as a junior you'll never get a chance to become Senior. How's that for a Catch 22?
Wrong is evil and must be defeated. - Jeff Ello
-
From personal experience - knowing: 1. what Visual Studio is and how to use it 2. how to debug code 3. how to write code that is testable through a test fixture 4. wait, even before #3, the concept that you have to test your code (true story) 5. how to tease apart requirements into an architecture that abstracts where things need to be abstracted, etc. 6. how to write a specification so someone can write the code for it 7. oh wait, before #6, how to write/communicate. (I got hammered as a kid for using "it" and "that", a lesson I took to heart many moons ago) 8. etc.etc.etc. But ultimately, the true difference between a junior and a senior developer is: The ability to say, and the frequent use of, the word NO Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Marc Clifton wrote:
The ability to say, and the frequent use of, the word NO
Very true, but I'd go further, to say "The ability to say, and the frequent use of, the word NO whilst being able to justify your reasons in a way a project manager can understand."
-
From personal experience - knowing: 1. what Visual Studio is and how to use it 2. how to debug code 3. how to write code that is testable through a test fixture 4. wait, even before #3, the concept that you have to test your code (true story) 5. how to tease apart requirements into an architecture that abstracts where things need to be abstracted, etc. 6. how to write a specification so someone can write the code for it 7. oh wait, before #6, how to write/communicate. (I got hammered as a kid for using "it" and "that", a lesson I took to heart many moons ago) 8. etc.etc.etc. But ultimately, the true difference between a junior and a senior developer is: The ability to say, and the frequent use of, the word NO Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Marc Clifton wrote:
The ability to say, and the frequent use of, the word NO
I prefer to take the approach of giving all the necessary information to the decision-makers (the costs, benefits, estimates, approximate time-scales, impact etc etc) and let them make the decision. Then it's on their heads not mine. If they say yes to something that is really stupid, then that's entirely their decision. As an example of this, in a previous company (who shall remain nameless to spare the innocent) we were asked to estimate how long it would take to convert a major part of the application from Classic ASP to ASP.NET. The team took a day off site and together we came up with our best estimate of 9 months. The CTO had already told one of our big clients we could do it in 3 - 4 months. We told him it was impossible. He cajoled us with overtime and a bonus payment if we succeeded. We told him again it was nothing to do with the money, there just wasn't enough time and people. Suffice to say we didn't hit the target. Over the course of the next 12 months the entire development team left (including myself) and eventually he was fired. There are always consequences to be paid for ignoring the advice of those who are best positioned to give that advice.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
From personal experience - knowing: 1. what Visual Studio is and how to use it 2. how to debug code 3. how to write code that is testable through a test fixture 4. wait, even before #3, the concept that you have to test your code (true story) 5. how to tease apart requirements into an architecture that abstracts where things need to be abstracted, etc. 6. how to write a specification so someone can write the code for it 7. oh wait, before #6, how to write/communicate. (I got hammered as a kid for using "it" and "that", a lesson I took to heart many moons ago) 8. etc.etc.etc. But ultimately, the true difference between a junior and a senior developer is: The ability to say, and the frequent use of, the word NO Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Some are born as a senior, most however as unfortunate as it is will never become one...
-
Marc Clifton wrote:
The ability to say, and the frequent use of, the word NO
If you use the word NO as a junior you'll never get a chance to become Senior. How's that for a Catch 22?
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
If you use the word NO as a junior you'll never get a chance to become Senior. How's that for a Catch 22?
Good point. Still, someone who constantly says yes is definitely junior. ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Marc Clifton wrote:
The ability to say, and the frequent use of, the word NO
Very true, but I'd go further, to say "The ability to say, and the frequent use of, the word NO whilst being able to justify your reasons in a way a project manager can understand."
Wastedtalent wrote:
he ability to say, and the frequent use of, the word NO whilst being able to justify your reasons in a way a project manager can understand.
Very true, and I'd add, from my experience working with management, say no but have at least one (preferably two or three) alternative options in hand. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Marc Clifton wrote:
The ability to say, and the frequent use of, the word NO
I prefer to take the approach of giving all the necessary information to the decision-makers (the costs, benefits, estimates, approximate time-scales, impact etc etc) and let them make the decision. Then it's on their heads not mine. If they say yes to something that is really stupid, then that's entirely their decision. As an example of this, in a previous company (who shall remain nameless to spare the innocent) we were asked to estimate how long it would take to convert a major part of the application from Classic ASP to ASP.NET. The team took a day off site and together we came up with our best estimate of 9 months. The CTO had already told one of our big clients we could do it in 3 - 4 months. We told him it was impossible. He cajoled us with overtime and a bonus payment if we succeeded. We told him again it was nothing to do with the money, there just wasn't enough time and people. Suffice to say we didn't hit the target. Over the course of the next 12 months the entire development team left (including myself) and eventually he was fired. There are always consequences to be paid for ignoring the advice of those who are best positioned to give that advice.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
Dominic Burford wrote:
Over the course of the next 12 months the entire development team left (including myself)
Which is the ultimate "no." :)
Dominic Burford wrote:
and eventually he was fired.
While it's on their heads, its unfortunate, because really everyone ends up paying the cost, even if you did move on to a better (or at least equivalent) job. Hopefully better, by the sound of what was going on where you were! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Marc Clifton wrote:
The ability to say, and the frequent use of, the word NO
I prefer the "Yes, but..." approach, followed by a list of things that paints the business leader into making the "No" decision, or extending the timeline and budget by 200%.
Vark111 wrote:
followed by a list of things that paints the business leader into making the "No" decision
plus, as I've learned, suggesting a couple alternative paths that try to meet the issues at least half way. ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Some are born as a senior, most however as unfortunate as it is will never become one...
gstolarov wrote:
Some are born as a senior, most however as unfortunate as it is will never become one...
I disagree. At least in this field, we're all born junior, and certainly in my experience (self-taught, no degree, no formal schooling) the reason I'm recognized as senior is because of my demonstrable accomplishments -- I've never met anyone that had senior qualifications that was actually in a junior position. Well, maybe because the company has become gentrified, but those people have always found other work that recognizes their talents (me included in that situation once, many many years ago -- really it was the defining moment of when I stopped being junior and, while not quite senior at that time, was definitely on that path from that moment on. And heck, with all the technology changes going on every day, there's a lot of things I can point at and say, yeah, I'm junior in that, but the difference is, I have years of experience that make me senior at how to learn something new.) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
A senior developer knows what NOT to do.
-
Dominic Burford wrote:
Over the course of the next 12 months the entire development team left (including myself)
Which is the ultimate "no." :)
Dominic Burford wrote:
and eventually he was fired.
While it's on their heads, its unfortunate, because really everyone ends up paying the cost, even if you did move on to a better (or at least equivalent) job. Hopefully better, by the sound of what was going on where you were! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
I would like to think the people involved in making their decisions learnt some valuable lessons. Life can be tough and unforgiving, and there is no short-cut towards experience and knowledge. People need to make mistakes so they can learn :)
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter