Personally, i don't equate professionalism with "nice". Nice is just a pc term for passive aggressive. To me at least, professionalism means not making or taking things personally. I've seen too many people that get offended when someone questions their ideas and treats it as a personal attack. Being nice seeks to avoid upsetting those people, not being professional. On the contrary, if you are professional you must confront those ideas to ensure the best solution is reached.
It is letting "nice" companies redefine the term prodessionalism to twist it into being what they want to make you look foolish by arguing against that we really need to stop.
For too long, corporate managers have applied a one-size-fits-all methodology (EG — agile), eliminating with extreme prejudice any developer that doesn’t fit that mold.
At last someone that finally understands that the agile madness is destroying your developers team. It does not improve your team, it brings down the team to the worst developer. Of course when everyone matches your worst developer, then you have no way to know anymore if your team has any worth.
I understand where the agile thing is coming from, you are trying to model your best developers, to do exactly like them. Then create some rules and let other repeat these rules hoping you get exactly the same results. But by doing this, you miss the whole point why these great developers are good in the first place: Because they have the freedom to invent and create new tools to build your project.
There is nothing wrong with being "professional" - it simply means you leave your personal problems behind. No one wants someone pushing their personal idealogy / religion / anti-religion / political view / problem with bf/gf / ect. in the workplace. It is anti-productive and shifts the focus from solving work problems to solving personnel problems.
On the flip-side, I think employers need to fuck off with being concerned with what employees do in their personal time.
I don't think the article said anything about personal problems. It is partly saying that trying to treat the development process as an automatable and regimented process is likely to disincentivize talented devopers. It is also speaking to the whole political correctness thing that is being taken to the absurd extreme that it is these days. I have been developing for about 30 years, am 100% self taught, am proficient with all of the popular languages and methodologies, worked in dozens of different companies of all sizes, and have simply given up trying to accomplish anything of real value. For about a year now I have worked a simple little part-time job. I have zero stress, and use all my extra time working with and on open source projects. The quality of my life has improved tremendously and I have regained the passion for development that originally started me on this journey so long ago. It's a shame really, but I am so tired trying to force square pegs into round holes for people who don't know what they are doing.
Since it was brought up, the original idea behind agile development is really good. The problem is when unimaginative organizations and managers try to force it down everyone's throat for every type of development scenario. And fuck the scrum bullshit.
Development is an art. Good development is done by good artists. The best development is done by someone who looks at the problem to be solved and selects the best tools and methodologies to effect a solution. One size does not fit all in development. This is what the corporate ass hats will never want to understand. They try to turn development into a science, where it can be quantified and measured. It just doesn't work this way.
Remember this the next time a piece of software ships with bugs or has otherwise senseless features. Or when a piece of hardware fails or doesn't talk to your other hardware. The next time you have a technology related wtf moment, you can probably blame some mid-level management retardation somewhere.
I gotta debate the following statement made in this article:
working in Agile is like being a teenager working at McDonalds — there are so many processes and suffocating constraints that few expert cooks (or in our case, engineers) can reach a reasonable fraction of their potential
If your processes are overwhelming you, you are not doing agile. Executable code is the the benchmark measurement of progress in agile, and if something you are doing is not working, change it. This is agile. If these don't match your current process, you are not doing agile, you are merely going through the agile motions and calling it agile. And nobody has ever produced anything of worth by just going through the motions.
5 comments
6 u/justcause 24 Jan 2016 01:30
Personally, i don't equate professionalism with "nice". Nice is just a pc term for passive aggressive. To me at least, professionalism means not making or taking things personally. I've seen too many people that get offended when someone questions their ideas and treats it as a personal attack. Being nice seeks to avoid upsetting those people, not being professional. On the contrary, if you are professional you must confront those ideas to ensure the best solution is reached.
It is letting "nice" companies redefine the term prodessionalism to twist it into being what they want to make you look foolish by arguing against that we really need to stop.
4 u/roznak 24 Jan 2016 02:31
At last someone that finally understands that the agile madness is destroying your developers team. It does not improve your team, it brings down the team to the worst developer. Of course when everyone matches your worst developer, then you have no way to know anymore if your team has any worth.
I understand where the agile thing is coming from, you are trying to model your best developers, to do exactly like them. Then create some rules and let other repeat these rules hoping you get exactly the same results. But by doing this, you miss the whole point why these great developers are good in the first place: Because they have the freedom to invent and create new tools to build your project.
3 u/Samsquamch 24 Jan 2016 05:10
There is nothing wrong with being "professional" - it simply means you leave your personal problems behind. No one wants someone pushing their personal idealogy / religion / anti-religion / political view / problem with bf/gf / ect. in the workplace. It is anti-productive and shifts the focus from solving work problems to solving personnel problems.
On the flip-side, I think employers need to fuck off with being concerned with what employees do in their personal time.
0 u/express-o 24 Jan 2016 06:34
I don't think the article said anything about personal problems. It is partly saying that trying to treat the development process as an automatable and regimented process is likely to disincentivize talented devopers. It is also speaking to the whole political correctness thing that is being taken to the absurd extreme that it is these days. I have been developing for about 30 years, am 100% self taught, am proficient with all of the popular languages and methodologies, worked in dozens of different companies of all sizes, and have simply given up trying to accomplish anything of real value. For about a year now I have worked a simple little part-time job. I have zero stress, and use all my extra time working with and on open source projects. The quality of my life has improved tremendously and I have regained the passion for development that originally started me on this journey so long ago. It's a shame really, but I am so tired trying to force square pegs into round holes for people who don't know what they are doing.
Since it was brought up, the original idea behind agile development is really good. The problem is when unimaginative organizations and managers try to force it down everyone's throat for every type of development scenario. And fuck the scrum bullshit.
Development is an art. Good development is done by good artists. The best development is done by someone who looks at the problem to be solved and selects the best tools and methodologies to effect a solution. One size does not fit all in development. This is what the corporate ass hats will never want to understand. They try to turn development into a science, where it can be quantified and measured. It just doesn't work this way.
Remember this the next time a piece of software ships with bugs or has otherwise senseless features. Or when a piece of hardware fails or doesn't talk to your other hardware. The next time you have a technology related wtf moment, you can probably blame some mid-level management retardation somewhere.
2 u/Acerebral 24 Jan 2016 09:16
I gotta debate the following statement made in this article:
If your processes are overwhelming you, you are not doing agile. Executable code is the the benchmark measurement of progress in agile, and if something you are doing is not working, change it. This is agile. If these don't match your current process, you are not doing agile, you are merely going through the agile motions and calling it agile. And nobody has ever produced anything of worth by just going through the motions.