Jeanne Boyarsky wrote:
In that case, I hope I never stop doing what you call "junior developer" work. I don't think it is a bad thing. Let's look at an example:
Jeanne Boyarsky wrote:
Suppose you need code that reads a file, removes all the lines the pattern MM/DD/YYYY and writes it back. I think we'd agree this is something a junior developer can do. I can write it in three minutes. (with one more two make it maintainable.) A junior developer is going to take significantly longer. Suppose it takes a junior developer fifteen minutes (which I think is optimistic.) I don't earn five times the salary of a junior developer so it isn't a waste for me to do it. Plus it was fun.
Jeanne Boyarsky wrote:
The three minute solution:
The maintainable refactoring that I spent one minute on top of the existing code.
Jeanne Boyarsky wrote:
Lucian Whiteman wrote:This is why someone who only does senior work is much more better than you. And has a much higher paycheck.
That's mildly insulting. Luckily the people I work with don't agree with you. Nor do people in user groups or many other places. I'm glad that I don't work wherever you do that thinks senior developers shouldn't be allowed to do any "easy" tasks.
Jeanne Boyarsky wrote:
Lucian Whiteman wrote:Wrong. During the hours you are doing junior dev work you are simply doing junior dev work. Hire a junior for that because his time is much cheaper.
No. The junior developer is cheaper because he/she gets less done. Part of this is not having the skills/experience of a senior developer. But part of it is taking longer to get the same work done. See my example above. When I code, I'm MUCH faster that a junior developer.
Jeanne Boyarsky wrote:
I'm not sure what this "senior" dev work is. I do a mix of things. Some could be done by a junior developer (like coding an implementation for an API). I do it much faster and better, but it could be done by a junior developer. Does that mean I do junior development work?
Jeanne Boyarsky wrote:
On my team, we don't happen to have any junior developers at the moment. Everyone on the team has more than 10 years of programming experience. So we don't sit around thinking about what "junior dev" work is. There's work. There's problems to be solved. We do it. We don't sit around making a hierarchy of work. We have had interns in the past. We paired more then. We did more up front analysis so the person could do some work independently. But it was carving out work the person could handle. And we had a junior developer on the team at one point. She needed more explanation and coaching on tasks, but did plenty.
Jeanne Boyarsky wrote:
I don't like the term "senior dev work". I like "senior dev skills." A senior developer brings up certain things, thinks more about non-functional requirements/maintenance/future changes, has more vision, etc. And that's something that nobody can take away because you are doing some kind of "lower level work." You do it better and it becomes "senior" work. I think that is a key difference. A senior developer is more likely to say something if asked to do something inefficiently or wrong. A junior developer is more likely to just do it.
Jeanne Boyarsky wrote:
Let me ask you this: who on your "Scrum" team does the analysis, design and other 'senior developer work." If it isn't the people on the Scrum team, I'm puzzled who is left.
Paul Clapham wrote:
Lucian Whiteman wrote:Take a look at 10 companies usign agile and 10 using waterfal - for all levels begginer/medium/senior the paychecks are the same !!!
Right. So that does demonstrate that programmers don't earn less money when working in an 'Agile" environment, as Tim said. I don't know how you interpret that statement as a contradiction of what Tim said.
Or at least it would demonstrate that if it were true. In most places it would be extremely difficult to survey 10 companies and find out what their salary ranges were and what development styles they were using. Practically impossible, really. But do you have an actual example of that from some country?
Jeanne Boyarsky wrote:
Lucian Whiteman wrote:Now open you eyes and ask yourself this: if I as an agile developer need twice as much time to become a senior compared to me working using waterfall, how much money does that cost me ?
I read the entire thread and don't see where this assertion comes from. Why do you believe it takes an agile developer twice as much time to become a senior developer?
Tim Cooke wrote:
Lucian Whiteman wrote:How much money does each programmer loses daily (through lower wage and lower opportunity) because of the Agile scam ?
I believe that programmers don't earn less money and have less opportunity when working in an 'Agile' environment as opposed to some other environment.
Tim Cooke wrote:
Lucian Whiteman wrote:... my question about Agile being a scam.
Would you mind clarifying exactly what your question is please? Mostly what I'm seeing here is a vigorously defended opinion.
Junilu Lacar wrote:
Lucian Whiteman wrote:
8) Since no 2 atoms can be in the same place at the same time, no 2 persons can do the same thing at the same time. For all the 'debaters' out there: if I press the button 'a', and my colleague presses that same button 'a' at the same moment, there are 2 different buttons pressed. No semantics disagreements to claim that 2 persons can work on the same thing at the same time.
This is a perfect illustration of the attitude that Tim points out. Your literal interpretation of "working on the same thing at the same time" has nothing to do with the collaborative nature of agile software development. On my teams, we do pair and group programming all the time and the software we produce through this practice is far more superior to the software that any single developer on our team working solo can produce.
Tim Cooke wrote: Have we now moved on to another false proposal that Agile hinders your professional development?
Tim Cooke wrote:
Let's take my work as an example. I work with electronic trading systems. If I were to follow your proposal for progressing my career quickly would I have to focus on a small part of the product only to do so? Should I focus all my efforts solely on the part of the system that sends email notifications to our customers, say? Should I avoid gaining knowledge on all other parts of the system because it would cause me to be less skilled in the email sending part?
Tim Cooke wrote:
Which engineer do you think is more valuable to a company: The guy who knows everything about the email sending part of the system? Or the guy who has a broad understanding of the entire system and its interactions within the larger ecosystem of a trading platform? Which guy would you promote first?
Tim Cooke wrote:I'm not saying that Agile doesn't require you to plan from the start. So what do you think I'm claiming Agile is better than?
Tim Cooke wrote:Does that mean you should stick to the plan no matter what? Even if the knowledge you had when you made the plan turns out to be wrong? Even if the customer made a mistake in their requirements? Even if you find out later you made a bad plan? How do you manage these unforeseen events with an "upfront plan at all costs" approach?