Are developers losing their independence?
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
Nothings changing, it's all a matter of the particular person you end up working for. The way your managers try to manage you, is going to be colored by their experience and their managing abilities. There is something to be said for experiencing many different types of employment, companies, and managers. Something you should also try an observe if possible, is the long-term evolution of a senior-developer jumping up into the senior-management ring. Over the coarse of months you will witness how they soon start to over-simplify the details that made certain aspects of the code quite complicated and the learning process it took to get to that point of understanding. One possible cause of being micro-managed and given no autonomity is the manager is in over their head. Managing people is a soft-skill directing people towards the "right" decisions. Making tangible decisions for the developers is sometimes the only way they feel they have any control in a situation where they are a bit lost. There are tons of great managers out there. There are also tons of great potential managers out there that just need a little bit of guidance from the developers they manage. Unfortunately, there are also a ton of horrible managers that just will not listen. One of your challenges, is to figure out what type you work for, and act accordingly.
All of my software is powered by a single Watt.
-
Yep. One has to earn authority and independence. It is not a given thing. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Did I give you permission to speak??? :-)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Did I give you permission to speak??? :-)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
Shut up and go push some more paper. :mad:
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
CIDev wrote:
you should seriously consider looking around for a better place to work
Done and done and done again. I've had the same experience three times in a row, which is a big anomaly in a 30 year career. I need to know how to calibrate my expectations.
Is there any common ground between your three experiences, such as business domain perhaps? I've only had this once in ten years. I know 1 in 10 is technically pretty much equivalent to 3 in 30, but I've had quite a few jobs in those ten years, and the one case was a real prick and I only worked there for two months.
-
You mean more developers are getting married these days? Seriously, if you want to work with managers who understand developers, find a job at a software company.
-
A good manager will know when to defer to a developer and when not to. Yes, there are good and bad managers but even the bad ones, should they have enough experience, know when to shutup and listen to someone with more knoweledge than themselves - it might just be that you don't assert yourself sufficiently.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
mark merrens wrote:
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."
As long as the amateur knows how to praise the other amateurs, things seems to work out quite well, making them professionals, sort of ;)
Espen Harlinn Senior Architect, Software - Goodtech Projects & Services
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
I have been in the industry for about 10 years, so I can not from first hand say what happenned before my time. I don't think that this is a present or past situation though, I believe it is on the companie's way of dealing with developers. I have been working as part of companies in full time jobs, outside as contractor, mixed as a consultant developer for third party companies... In all cases the situation you are describing covers about 60-70 percent of the cases. Managers except very few cases lack the technical knowledge and I have seen cases where they have technical knowledge of some sort and then you would wish they had none. Because then they think they know what you are referring to but in most cases have a complete total blanc of what is going on. On the other hand, freedom in the scope of a developer is a tedious notion. If I was managing developers I would want them programming the way they want but would offer guidelines, quite strict on basic principles that should be adopted, as which DAL would be used, the work should be reusable and in framework way etc. But that would be done by a so called "Technical Manager". The worse case I have been involved in was taking erroneous guidelines on working on a specific way that the solution developed did not even handle correctly. And trying to work knowing the fact that what I was doing is wrong, unsafe and would cause problems in speed and reusability. That happenned in a huge company, where most people where employed because of their connections and not -in any way- their knowledge and expertise. Needless to say our cooperation ended very quickly. It seems that smaller (small to medium size) companies do respect their staff more and depend on your work so they can't but give you freedom. On the other hand I had a recent case, working as a freelancer for a very small company, where I was asked, in a very crude way, to hand out source code for dll's that included my personal framework, or to design a database in a very primitive way, just because the "other programmer" (the one they actually employed) is not familiar with a relational database... So I guess the problem is there, you're not unlucky!
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
Your experience is not unique, but the cloud has a silver lining: Managers are unlearning the most pernicious of these practices, under the lash of experience.
The disease took its first form with the Capability Maturity Model (CMM), which, in essence, told managers that they could measure, and therefore control, the engineering "process." It was a lie from the very first, but it seduced an awful lot of "spreadsheet pilots" (my personal derogation for managers who think the complexities and sophistications of any engineering undertaking can be meaningfully measured or reproduced) into thinking they could guarantee something that God Himself has made un-guarantee-able: the ultimate functionality, overall cost, and time-to-completion of an R&D project.
Matters became really grave with ISO-9000, which purports to codify how engineering should be done. In point of fact, the only thing about engineering that can even be described was summed up in the old "waterfall" description of a project -- and that description is notional rather than intensive. But the ISO-9000 enthusiasts (once again, managers with an unshakable conviction in the precise manageability of absolutely everything, even if it's never been done before, nor anything like it) were adamant. In this, they had backing from a number of large institutions, most notably the federal government, which made the ultimate cauterizing of the wound that much more painful.
But the universe has its laws, and it grants no exemptions from them. One of those laws is that no one can nail down all three vertices of the development triangle:
- If you rigidly specify functionality and cost of development, the time to completion will be unknown.
- If you rigidly specify functionality and time to completion, the cost of development will be unknown.
- If you rigidly specify cost of development and time to completion, you have no idea what the ultimate product will do!
It doesn't matter what your "process" is, or how you've documented and explained it, or what rewards (or punishments) you've promised for following (or not following) it. Managers learned this by imposing CMM and ISO-9000 on us, and reaping the whirlwind.
The best part of this is that the great majority of those managers thought their new management technique would make them look like aces in front of their customers, so, in the fas
-
I've worked at small companies too. It has come as a surprise to me when managers behaved as though the devs were simply coding monkeys, and decisions about directions needed to be kept away from them.
I've experienced that also (only once though) and saw the project head to failure because I wasn't given the liberty to implement the solution my way, which I knew it would work.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics/[^] Basically it says we are all nerds that don't know how important we are so acquire our talent and treat us like crap, we like it that way. Battered wife syndrome. There is a HORRIBLE gap in qualified tech leads these days. I just took over this process and found out that PM's don't know anything other than their projects (and they don't know them all that well) are the most important thing in the world, and web development is like using MS Word... it is too dorky and demeaning but they could easily do our jobs.
*--==[::tSc::]==--* TestShoot.com Film Supplies TBB aka P90X (my day job)
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
Member 2941392 wrote:
can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago?
Ten or fifteen years ago the same problem existed; in some organizations today, it doesn't exist. It's worst in organizations where the manager is a former developer, but it occurs everywhere. You just got lucky in your early experiences.
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
surprise me! :) I have been in both kinds of ships. 4 years ago, the company/project i was in, had a manager who was technically good but the politics killed everything, including developer freedom. Currently, at my work i have fair amount of autonomy and pretty much free rein towards design decisions, algorithms and implementation strategy. It is really productive, because this motivates you to do better every time, find more efficient and newer ways of solving problems.
-
Your experience is not unique, but the cloud has a silver lining: Managers are unlearning the most pernicious of these practices, under the lash of experience.
The disease took its first form with the Capability Maturity Model (CMM), which, in essence, told managers that they could measure, and therefore control, the engineering "process." It was a lie from the very first, but it seduced an awful lot of "spreadsheet pilots" (my personal derogation for managers who think the complexities and sophistications of any engineering undertaking can be meaningfully measured or reproduced) into thinking they could guarantee something that God Himself has made un-guarantee-able: the ultimate functionality, overall cost, and time-to-completion of an R&D project.
Matters became really grave with ISO-9000, which purports to codify how engineering should be done. In point of fact, the only thing about engineering that can even be described was summed up in the old "waterfall" description of a project -- and that description is notional rather than intensive. But the ISO-9000 enthusiasts (once again, managers with an unshakable conviction in the precise manageability of absolutely everything, even if it's never been done before, nor anything like it) were adamant. In this, they had backing from a number of large institutions, most notably the federal government, which made the ultimate cauterizing of the wound that much more painful.
But the universe has its laws, and it grants no exemptions from them. One of those laws is that no one can nail down all three vertices of the development triangle:
- If you rigidly specify functionality and cost of development, the time to completion will be unknown.
- If you rigidly specify functionality and time to completion, the cost of development will be unknown.
- If you rigidly specify cost of development and time to completion, you have no idea what the ultimate product will do!
It doesn't matter what your "process" is, or how you've documented and explained it, or what rewards (or punishments) you've promised for following (or not following) it. Managers learned this by imposing CMM and ISO-9000 on us, and reaping the whirlwind.
The best part of this is that the great majority of those managers thought their new management technique would make them look like aces in front of their customers, so, in the fas
I'm afraid I disagree with nearly every word of what you say. Some of my best managers pursued software process improvement in a thoughtful and effective manner. And ISO 9000 is a far more flexible tool than the CMM, allowing a variety of different processes to fit the specific industry and type of software being developed. The whole Agile movement (which has its own problems) is an attempt to repeat the dev process enough times that you eventually get control of it. I don't think this is the one yardstick that will measure the quality of a manager (ouch, meta-humor). This post needs to be the root of a whole 'nother rant. But I love your style.
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
Except for one job and my current position as a manager, you just described my 35+ year career. I've worked at places where managers ruled primarily by intimidation. The fact that they were the managers made them inherently superior beings. Only one place comes to mind where the manager assumed you were an adult and knew what you were doing. He was fired as the scapegoat for disasters created by the salesmen. I missed him. The manager that replaced him was a complete idiot who felt he (or was told) he had to bring an out of control department back to order. As a manager now, I assume all my minions are adults who want to express themselves by doing their best. I understand that I will not be able to micromanage them because I do not have the time to keep up with the intricacies of their projects and development languages. But I do know how to smell BS in status reports. I feel everyone is unique and brings different capabilities to their projects. It is my job to find a way that their skills can be used optimally. It is also my job to act as facilitator as to make their jobs easier. And lastly, it is my job to council them with my life's experiences on how to avoid the common pitfalls in software development. I want code that is maintainable, not just cranked out quickly to spec. I want test scripts that are written to be used by people not familiar with the code. I want people who will collectively dream of creating code that exceeds the expectations of my management and our users.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it. As suggested by GamleKoder... For efficiency, should not this read: Those who do not remember the past { are doomed to repeat it. cannot build upon it. } ;-)
-
Your experience is not unique, but the cloud has a silver lining: Managers are unlearning the most pernicious of these practices, under the lash of experience.
The disease took its first form with the Capability Maturity Model (CMM), which, in essence, told managers that they could measure, and therefore control, the engineering "process." It was a lie from the very first, but it seduced an awful lot of "spreadsheet pilots" (my personal derogation for managers who think the complexities and sophistications of any engineering undertaking can be meaningfully measured or reproduced) into thinking they could guarantee something that God Himself has made un-guarantee-able: the ultimate functionality, overall cost, and time-to-completion of an R&D project.
Matters became really grave with ISO-9000, which purports to codify how engineering should be done. In point of fact, the only thing about engineering that can even be described was summed up in the old "waterfall" description of a project -- and that description is notional rather than intensive. But the ISO-9000 enthusiasts (once again, managers with an unshakable conviction in the precise manageability of absolutely everything, even if it's never been done before, nor anything like it) were adamant. In this, they had backing from a number of large institutions, most notably the federal government, which made the ultimate cauterizing of the wound that much more painful.
But the universe has its laws, and it grants no exemptions from them. One of those laws is that no one can nail down all three vertices of the development triangle:
- If you rigidly specify functionality and cost of development, the time to completion will be unknown.
- If you rigidly specify functionality and time to completion, the cost of development will be unknown.
- If you rigidly specify cost of development and time to completion, you have no idea what the ultimate product will do!
It doesn't matter what your "process" is, or how you've documented and explained it, or what rewards (or punishments) you've promised for following (or not following) it. Managers learned this by imposing CMM and ISO-9000 on us, and reaping the whirlwind.
The best part of this is that the great majority of those managers thought their new management technique would make them look like aces in front of their customers, so, in the fas
At my last job we were forced to read "Who moved my cheese" and "Sojourner, An Insider’s View of the Mars Pathfinder Mission" (faster, better, cheaper mantra). The first, we guess was just to remind us that we were just rats in a maze and had us wondering if we should have continued the metaphor by leaving the sinking ship. (I loved the part of the book were the characters in it raved about metaphor of mice in a maze looking for cheese. Talk about rabid self-promotion...) The second, while it was supposed to be a blueprint for our software development (like plan on firing 10% of your staff for being incompetent), given that the two following space missions constructed with that methodology were failures, made the success of the first a statistical fluke. And to state your rules succinctly: Fast, Good, Cheap...Choose two.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
It seems to me, since about 2008 or so, that all the jobs I've taken have been at places where managers (of no particular skill, experience, or intelligence) have reserved all design authority to themselves, and expected the development team to just keep their heads down and do as they're told. I can't sample enough jobs to know if this is a trend or if I've just gotten unlucky a few times. Anyone else feel like companies are reducing the scope of freedom of developers, versus say 10-15 years ago? Is there anyone who, having seen this trend, thinks it's a Good Thing?
In the last two jobs I've worked at (in Mexico), developers pretty much were given a task, an arbitrary deadline and arbitrary requirements changes (with no reasonable rationale behind either), and then left alone until release and testing.
-
http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics/[^] Basically it says we are all nerds that don't know how important we are so acquire our talent and treat us like crap, we like it that way. Battered wife syndrome. There is a HORRIBLE gap in qualified tech leads these days. I just took over this process and found out that PM's don't know anything other than their projects (and they don't know them all that well) are the most important thing in the world, and web development is like using MS Word... it is too dorky and demeaning but they could easily do our jobs.
*--==[::tSc::]==--* TestShoot.com Film Supplies TBB aka P90X (my day job)
That's why I'm planning on starting my own software shop where devs are the most important asset (a la Spolsky), I'm sick & tired of working 100 hour-weeks 3 months straight, and getting paid no overtime, not even a pat on the back. Fuck that.