Win a copy of Pipeline as Code this week in the Cloud/Virtualization forum!

Lucian Whiteman

Ranch Hand
+ Follow
since Jun 14, 2015
Cows and Likes
Cows
Total received
-2
In last 30 days
0
Total given
0
Likes
Total received
6
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Lucian Whiteman

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:



What about all the other developers who do not wish to do junior work ? Do you enjoy them being forced by SCRUM to do junior work for way longer than they should ?

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.



There are juniors who do this stuff in 3 hours, and there are juniors who do this in less than 3 minutes. Let us not insult any of them by claiming that it will take a lot of time for all.


Jeanne Boyarsky wrote:
The three minute solution:



The maintainable refactoring that I spent one minute on top of the existing code.



You believe you are better than a junior, yet you format the code way worse than the juniors I teach. My good man(or woman), here is a free formatting lesson for you:



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.



What about the people who agree with me ? Do we not matter ?

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.



First, let us not insult juniors by claiming they all get less done every single time. Secondly, let us not insult juniors by claiming that whenever junior get the skills needed for a task they still are slower than a senior. I thought racism was not tolerated on this forum. Yet I see this user claiming that a category of people is worse(slower) than another, even if they were to have the same initial skills and training.


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?



Yes it does ! That pretty much is the definition of it.

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.



This is why someone who only does senior work is much more better than you. And has a much higher paycheck.

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.



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.
Guys and girls: you are simply wasting my time.

I wrote this post to ask people how they react to the scam that agile scrum is, and most of you keep on claiming that I am wrong to say agile scrum is a scam.Please post here only if you believe , like I do, that it is a scam and harmful to developers. If you do not believe than then stop posting here as you are only trolling me.

There are plenty of consultants that get rich by preaching agile scrum as a religion. It is only normal for them to go on the internet and claim agile is not a scam whenever someone asks about it.


Take a look at this post: a lot of people repeating the same words "it is not a scam, you are not just doing it right". None of them bother to actually consider who pays for the consultants salaries and why so many managers are too eager to change to agile. Where does this extra money and productivity comes from ? I say it comes out of developer having lower paychecks and working overtime, yet you do not even acknowledge this.

Admins start doing your job please !

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.



This is precisel my point: " the analysis, design and other 'senior developer work." is what one needs to become a senior, and in a scrum team everyone does an equal little bit of that. Compared to other approaches where one would get to do mostly that (if not only that) once he gathers experience.

Compare 10 months of doing 10% senior developer job and 90% junior developer - this is SCRUM, with another approach where you get to a point where you do 90% senior dev job and only 10% junior.

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?



Come on ! I know you want to defend scrum, but really ?!

So one guy is a beginner for 5 years (them middle level for another 5, with a greater pay check), and another one is a junior for 10 because he uses scrum. Though both have at first the same junior paycheck, you claim that those 2 earn the same during those 10 years !?

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?



In SCRUM each developer is an "interchangeable cog". Thus you get to do repetitive monkey job a lot.

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.



In every country there are sites that show the average paycheck of java developers. Take a look at 10 companies usign agile and 10 using waterfal - for all levels begginer/medium/senior the paychecks are the same !!!


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 ?

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.



My initial question:
How much money does each programmer loses daily (through lower wage and lower opportunity) because of the Agile scam ?

Further questions:
How much of that money goes to the Agile "coaches" and how much does it go elsewhere ?
Who are the ones who betrayed us and profited out of this scam ?
How can we punish the ones who robbed us through the Agile scam ?
How can we make sure such scams never occur again ?

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.



My good man, this is the example of your dismissive attitude. You claim that "software we produce through this practice is far more superior to the software that any single developer on our team working solo can produce".

This has zero relevance to the topic ! Sure you will write better code if someone is sitting next to you and gives you and extra opinion about it, nobody ever claimed otherwise. Yet this has nothing to do regarding my question about Agile being a scam.

In order for your example to have relevance to the topic, you must take a team working in pairs using agile, and another one working in pairs without agile, then compare the 2.

Tim Cooke wrote: Have we now moved on to another false proposal that Agile hinders your professional development?



Until you have proven my proposal is false, you should not be hasty to proclaim it as so.

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?



You are deliberately being misleading. Maybe you fail to see that investing 10 consecutive days into learning all about that email system is more efficient than spending 20 days each separated by 2 weeks apart.

Maybe you fail to see that investing 10 consecutive days in A (the email system), then 10 consecutive days in A2, then 10 in A3, ..., and finally 10 consecutive days in A10 - is much better than investing 1 day in A1, then 1 day in A2 then 1 day in A3,..., then 1 Day in A10 then again 1 day in A1 and so on.

I never claimed you work on a single subject. I did claim that you work on more subjects, but you first get good with the first one then and only them move along. Stop trying to claim I said otherwise and please use real arguments.

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?



Obviously the one that knows all about the email system is more valuable than the one with moderate knowledge of the entire system, and both of them are more valuable than the one with little knowledge of the entire system. At least this is what their pay checks say.

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?




Let me explain a bit more clearer for everyone else. For purposes of debate I shall give numbers to my assumptions. Feel free to contradict me or approve with me:

1) Nobody is born knowing everything about java or IT
2) Learning something new takes time. There is a time cost that is always > 0.
3) A project takes a finite amount of time, from its day 1 to last day. Thus it takes N days (including weekends).
4) The only time you learn things while physically being at work are the times you physically are at work.
5) The time you are at work (working on that project) is less than those N days.
6) Hopefully by now we have established that the amount of time to learn, during the project you are working on, is finite (<= N days).
7) If there is more than 1 person in the team then each person int the team will work on something else in a certain given moment.
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.
9) The project will thus have N * P man days, where P = persons working on it.
10) Out of those N * P man days only N are mine.
11) Out of those N*P parts(slices of work) of the projects I can and will only do N or less.
12) If we choose parts at random I will learn some stuff about those parts. Thus if there are X fields of knowledge (who require equal work on) that can be learned in this project, I will only have N/X man days to learn about each.
13) If I only get to do the stuff regarding X, I will then have N man days for that field X and 0 for others.
14) Thus someone using Agile and being an "interchangeable cog" will know way less about X than someone who does only X.


Do you agree with me thus far ? Can you all see that the programmer pays a huge price for being an "interchangeable cog" , namely the price of not learning as much programming in those man days he puts in a project ?


15) How much less do I know about field of knowledge X if I only put in N/X compared to putting in N man days on it ? Here is something interesting, if you have a field of knowledge that required A days to become a beginner, B days to become intermediate and C days to become an expert, and C = 10* B and B = 10* A, and B is bigger than N/x then you will never be more than a beginner in A, and sometimes a lousy beginner.

This is why I say that Agile keeps you in a perpetual state of being a junior or at best intermediate in regards to some subjects. A well rounded junior, but still a junior, receiving the pay check of a junior.






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?



Surely having a plan from the start will have its drawbacks, but are you really thinking about claiming that Agile is better ?!