|
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
|
|
|
|
|
Sadly there are many companies (usually, but not limited to large ones) where the managers think they know more on technical issues than their technical people. If you are lucky you will be able to show them better ways to do things and they will accept it. If not then you should seriously consider looking around for a better place to work.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
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.
|
|
|
|
|
One of my early jobs was at a place that called themselves a software company and they had more accountants than programmers. Not surprisingly, it died in the early 1990s.
|
|
|
|
|
I haven't seen that, but there is something about losing the independence...
I've seen two things:
1. Managers who have learnt that they can't trust all design to developers.
Why? They tend to be too perfect and they tend to design too complex solutions.
Example: four weeks for develolpment of foolproof feature to overcome risk estimated to cause $10 loses per year...
2. Lost independence of choosing what developers are doing.
Some time ago (don't know if really 10 years) almost everything what was developped had some business value.
Now managers want to maximise business value of developped functionalities, so they started setting priorities and deciding whay to do.
|
|
|
|
|
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
|
|
|
|
|
Yep. One has to earn authority and independence. It is not a given thing.
|
|
|
|
|
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. 
|
|
|
|
|
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
|
|
|
|
|
i see no difference.
but maybe it's just the jobs i've had.
|
|
|
|
|
I have never worked anywhere where anybody else had a clue what I was doing - the only place which came close was a COBOL shop years ago working on Prime minis - so I taught myself the Prime OS language SPL (a PL/1 subset) and wrote my own programming language in it which I gave to the ops team to write all their data processing software in. That was fun when I left
|
|
|
|
|
I've had quite a bit of autonomy at all my jobs.
If there is any trend, it may be an increase of direct managers who are experienced with design. If they are good at it, its a very good thing. (At one point in my career, my direct manager was a writer. Good guy and very good at running interference for us, but he didn't know squat about programming. Fortunately, he knew this and acted accordingly.)
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
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 fashion of managers throughout history, they decided to "hog the limelight." Instead of kudos, they got clobbered.
As P.J. O'Rourke has said, "Pain is instructive. It teaches us that we're boneheads." Managers are learning, at a steady rate, that spreadsheets and hubris are no substitute for dedication and talent. Ultimately, the "process" fad will fade and be forgotten. Repentant managers willing to let it slip away into obscurity will recover. Perhaps the remainder will buy coffee trucks and stake out stretches along one or another of America's many highways.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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. F*** that.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
