For starters I'd recommend being adaptable, not every manager is the same and you should be able to react to whatever plusses your boss (if only to smooth out communication and process, not necessarily because they'll always be right or good).
I'm an engineering manager, and my expectations of my employees are openness, dedication, honesty, critical thinking skills, and either technical prowess or an honest acknowledgment of their limitations and a willingness/ability to grow. There's nothing worse than someone who doesn't know how to do something and is willing to allow the project to suffer rather than admit they don't know what to do. As a manager, part of my job is to make sure that I get the most out of you, limitations included. I don't want to fire you if I can avoid it -- hiring and firing are a huge pain in the ass. Reduce the opportunity cost of being fired by doing your best to contribute.
I will ask you them to work late hours sometimes, and I tell them upfront that it's part of the job. I don't try to do it often, because I respect my employees and I try to be fair -- but sometimes everyone's crunching, and hiring someone else isn't an option. I expect everyone to want the team to succeed, and I try to provide clarity on what "succeeding" means. I try to set clear goals for individuals, and let them know whether or not I feel they're meeting their goals on a regular basis. You should expect all these things too -- and if your manager is not doing one of these things, you should feel very comfortable telling her so.
Despite someone else's commentary on the subject above, flatly saying you will not work overtime or that you will not work on a weekend when I feel like it's absolutely necessary will reflect very negatively on you. Feel free to raise your objections or ask that I do a better job of preventing such situations from arising in the future. Take me to task, but don't refuse to do the thing that your leader feels is necessary for us to succeed.
If you don't respect your leader and you feel like you're competent, a strong developer, and experienced - establish yourself as being self-managing, take your manager to task frequently, and challenge decisions respectfully. You will eventually be left alone. If you don't respect your leader, and you're very very green -- you may just have to take the blows and try to make the most out of the experience. Most people have to eat a little dirt in the beginning.
If you accomplish something, don't be afraid to market yourself and pump it up. Lots of developers will feel as though they're unappreciated, but very few are any good at helping a manager understand the impact of obscure changes they've made. If it doesn't have a clear business impact, sometimes even a very good manager won't feel it was a big accomplishment unless you clarify it to them. Or, on the flipside, a good manager may be able to tell you "I don't think it was worth spending 8 weeks rewriting our caching layer for a 2% speed increase" and help you set yourself up for bigger accomplishments (or more impactful uses of limited time) in the future.
Development is often a creative endeavor, and like most creatives there are myriad opinions on what the most important aspects of the craft are. This article seems to come from the angle that "structured development solutions are paramount." I have worked with a lot of developers who fell into this camp, and generally I agree that any network of developers (whether a programming pair, project team, or whole web development community) should strive to create a development vocabulary that puts people on a common ground. However, this single-mindedness ignores the fact that even this goal benefits from the waves and eddies caused by new models, new patterns, and experimental solutions that are the nature of what we do. We gain a lot from not treating a need for that structure as a limiting factor in how we evolve these technologies.
Web technologies are capable abstractions built on top of other more stable primitives. All programming languages and environments are just an ordering of primitives through various layers of abstraction. 1s and 0s are given meaning through a processor, assembly gives you a language to interact with that meaning, C creates a higher-level (but still generally considered low-level) abstraction to that, other languages are built on C (or interpreters are built on C) to simplify it further. As you go higher up the tower of abstraction, the more work you're trying to keep the developer from having to do themselves.
Many of the most contentious web technologies (PHP, HTML, Browsers, Javascript, CSS) exist on a pretty high tier of abstraction, and these and frameworks/environments built around these technologies have evolved with the goal of meeting the demands of an audience. It's mostly irrelevant at this point to say that a technology like Javascript is bad because "it was designed to make small interactive elements on a web page" -- because like all web technologies, it is evolving. PHP was created to do some very lightweight CGI tasks for its creator's resume website -- but 5 official versions later, it is used to drive many of the largest, richest applications on the Web - and it continues to evolve. All these things are getting more and more ordered -- hell, even Internet Explorer is responding to
standards on its newer browsers with a relatively impressive pace. At the same time, the industry is recognizing that as painful a road as it has been, it was all made possible by the fact that there were a silly number of choices for how to do something, and you had competing clients and implementations. Even now, while the HTML5 standard is looking like it help unify rich interactivity in a Web environment in a relatively widely adopted way, it was also written with the understanding that different browser vendors will choose to vary their implementations and introduce experimental features that they would like to see in future standards.
What you end up with is a competitive model based not only on end-user products, but on the quality of tools to create those products -- the main difference from similar models in other industries being that the tools we use are often ostensibly free. It's not the only way it could work, but I'd point out, and this is my main point: it has worked well
Well structured, elegantly written code or not - web technologies have served to grow a humongous industry, built on interfaces and platforms that we all appreciate and most of us can't imagine living without. It has worked very well. It'd be pretty hard to argue that you could have anticipated the design the web should have followed and been successful. The ease of adoption of these scrappy technologies has been essential to the Web's growth. As frustrating as it can be to see things done in a stupid way, sometimes the people for whom something is being designed don't care about how it was done, just that it was done. I, for example, know some of how Yahoo does (or used to do) their templating and localization, and I think it's one of the pug-fugliest solutions I'v
Well put! The only thing I'd add is that I think there may be a natural transition completed unrelated to The Peter Principle of competent engineers, and possibly even competent Technical Leads, becoming incompetent managers as time passes.
I think some of this happens because they either lose touch with or never understood why bad manager-techie relationships are sometimes bad in the first place. I definitely recommend spending time as a Technical Lead, and slowly working to eliminate your actual workload. The difference between a Technical Lead and a Manager is not just one of scope, but it's one of being able to trust the team you're managing with 100% of the engineering work. Have you ever felt like a project would fall apart without you actually laying down code? Do you think you'd be able to get it to that point? Once you do, take some time to acknowledge what made it work. That's an important quality of a good technical manager, I think, is being able to get a team to the point where you trust them. Micromanagers are micromanagers because they don't trust a team. They don't improve because their time is spent micromanaging, not getting a team to a point where he feels comfortable with their level of competence. It's easier (though ultimately less productive) to micromanage than it is to deal with personality issues, competence issues, and lacking enthusiasm in a team member.
I think a manager also, because they're not involved in the granular issues of the deliverables, has a tendency to come off as clueless. Sometimes they will try to solve this with micromanagement, status reports, weekly meetings, etc. Engineers hate that kind of stuff. It cuts into the productive flow, and doesn't benefit them directly. A good manager will figure out a communication structure that's non-intrusive, and will "market" it to engineers as though it's in their/the-company's best interests. If you can't convince them, then maybe it's not in their best interests. And yes, you should ask them if they agree, if only so they're on board with your decision. Unpopular decisions can be diffused as long as both parties come to an understanding about why those decisions were made. If they're still unpopular, then they might be bad decisions!
Don't let the stigma of management keep you from becoming a manager, use that stigma to avoid falling into the very negative archetype that you fear.
An actual techie might tell the customer his opinion. Techies aren't geniuses - often, they're more prone to a "Oo, shiny new technology" mentality than others. In fact, how many techies do you know who are willing to accept a completely broken product or first-generation technology because they're excited about what it could become, or what it stands for? I would almost argue that a dumbo floor salesman is trying to deliver to a customer something that the customer is more likely to understand and be able to use.
What consumer, who aren't techies, would want those things?
Slashdot Mirror
For starters I'd recommend being adaptable, not every manager is the same and you should be able to react to whatever plusses your boss (if only to smooth out communication and process, not necessarily because they'll always be right or good).
I'm an engineering manager, and my expectations of my employees are openness, dedication, honesty, critical thinking skills, and either technical prowess or an honest acknowledgment of their limitations and a willingness/ability to grow. There's nothing worse than someone who doesn't know how to do something and is willing to allow the project to suffer rather than admit they don't know what to do. As a manager, part of my job is to make sure that I get the most out of you, limitations included. I don't want to fire you if I can avoid it -- hiring and firing are a huge pain in the ass. Reduce the opportunity cost of being fired by doing your best to contribute.
I will ask you them to work late hours sometimes, and I tell them upfront that it's part of the job. I don't try to do it often, because I respect my employees and I try to be fair -- but sometimes everyone's crunching, and hiring someone else isn't an option. I expect everyone to want the team to succeed, and I try to provide clarity on what "succeeding" means. I try to set clear goals for individuals, and let them know whether or not I feel they're meeting their goals on a regular basis. You should expect all these things too -- and if your manager is not doing one of these things, you should feel very comfortable telling her so.
Despite someone else's commentary on the subject above, flatly saying you will not work overtime or that you will not work on a weekend when I feel like it's absolutely necessary will reflect very negatively on you. Feel free to raise your objections or ask that I do a better job of preventing such situations from arising in the future. Take me to task, but don't refuse to do the thing that your leader feels is necessary for us to succeed.
If you don't respect your leader and you feel like you're competent, a strong developer, and experienced - establish yourself as being self-managing, take your manager to task frequently, and challenge decisions respectfully. You will eventually be left alone. If you don't respect your leader, and you're very very green -- you may just have to take the blows and try to make the most out of the experience. Most people have to eat a little dirt in the beginning.
If you accomplish something, don't be afraid to market yourself and pump it up. Lots of developers will feel as though they're unappreciated, but very few are any good at helping a manager understand the impact of obscure changes they've made. If it doesn't have a clear business impact, sometimes even a very good manager won't feel it was a big accomplishment unless you clarify it to them. Or, on the flipside, a good manager may be able to tell you "I don't think it was worth spending 8 weeks rewriting our caching layer for a 2% speed increase" and help you set yourself up for bigger accomplishments (or more impactful uses of limited time) in the future.
Development is often a creative endeavor, and like most creatives there are myriad opinions on what the most important aspects of the craft are. This article seems to come from the angle that "structured development solutions are paramount." I have worked with a lot of developers who fell into this camp, and generally I agree that any network of developers (whether a programming pair, project team, or whole web development community) should strive to create a development vocabulary that puts people on a common ground. However, this single-mindedness ignores the fact that even this goal benefits from the waves and eddies caused by new models, new patterns, and experimental solutions that are the nature of what we do. We gain a lot from not treating a need for that structure as a limiting factor in how we evolve these technologies.
Web technologies are capable abstractions built on top of other more stable primitives. All programming languages and environments are just an ordering of primitives through various layers of abstraction. 1s and 0s are given meaning through a processor, assembly gives you a language to interact with that meaning, C creates a higher-level (but still generally considered low-level) abstraction to that, other languages are built on C (or interpreters are built on C) to simplify it further. As you go higher up the tower of abstraction, the more work you're trying to keep the developer from having to do themselves.
Many of the most contentious web technologies (PHP, HTML, Browsers, Javascript, CSS) exist on a pretty high tier of abstraction, and these and frameworks/environments built around these technologies have evolved with the goal of meeting the demands of an audience. It's mostly irrelevant at this point to say that a technology like Javascript is bad because "it was designed to make small interactive elements on a web page" -- because like all web technologies, it is evolving. PHP was created to do some very lightweight CGI tasks for its creator's resume website -- but 5 official versions later, it is used to drive many of the largest, richest applications on the Web - and it continues to evolve. All these things are getting more and more ordered -- hell, even Internet Explorer is responding to standards on its newer browsers with a relatively impressive pace. At the same time, the industry is recognizing that as painful a road as it has been, it was all made possible by the fact that there were a silly number of choices for how to do something, and you had competing clients and implementations. Even now, while the HTML5 standard is looking like it help unify rich interactivity in a Web environment in a relatively widely adopted way, it was also written with the understanding that different browser vendors will choose to vary their implementations and introduce experimental features that they would like to see in future standards.
What you end up with is a competitive model based not only on end-user products, but on the quality of tools to create those products -- the main difference from similar models in other industries being that the tools we use are often ostensibly free. It's not the only way it could work, but I'd point out, and this is my main point: it has worked well
Well structured, elegantly written code or not - web technologies have served to grow a humongous industry, built on interfaces and platforms that we all appreciate and most of us can't imagine living without. It has worked very well. It'd be pretty hard to argue that you could have anticipated the design the web should have followed and been successful. The ease of adoption of these scrappy technologies has been essential to the Web's growth. As frustrating as it can be to see things done in a stupid way, sometimes the people for whom something is being designed don't care about how it was done, just that it was done. I, for example, know some of how Yahoo does (or used to do) their templating and localization, and I think it's one of the pug-fugliest solutions I'v
Well put! The only thing I'd add is that I think there may be a natural transition completed unrelated to The Peter Principle of competent engineers, and possibly even competent Technical Leads, becoming incompetent managers as time passes.
I think some of this happens because they either lose touch with or never understood why bad manager-techie relationships are sometimes bad in the first place. I definitely recommend spending time as a Technical Lead, and slowly working to eliminate your actual workload. The difference between a Technical Lead and a Manager is not just one of scope, but it's one of being able to trust the team you're managing with 100% of the engineering work. Have you ever felt like a project would fall apart without you actually laying down code? Do you think you'd be able to get it to that point? Once you do, take some time to acknowledge what made it work. That's an important quality of a good technical manager, I think, is being able to get a team to the point where you trust them. Micromanagers are micromanagers because they don't trust a team. They don't improve because their time is spent micromanaging, not getting a team to a point where he feels comfortable with their level of competence. It's easier (though ultimately less productive) to micromanage than it is to deal with personality issues, competence issues, and lacking enthusiasm in a team member.
I think a manager also, because they're not involved in the granular issues of the deliverables, has a tendency to come off as clueless. Sometimes they will try to solve this with micromanagement, status reports, weekly meetings, etc. Engineers hate that kind of stuff. It cuts into the productive flow, and doesn't benefit them directly. A good manager will figure out a communication structure that's non-intrusive, and will "market" it to engineers as though it's in their/the-company's best interests. If you can't convince them, then maybe it's not in their best interests. And yes, you should ask them if they agree, if only so they're on board with your decision. Unpopular decisions can be diffused as long as both parties come to an understanding about why those decisions were made. If they're still unpopular, then they might be bad decisions!
Don't let the stigma of management keep you from becoming a manager, use that stigma to avoid falling into the very negative archetype that you fear.
An actual techie might tell the customer his opinion. Techies aren't geniuses - often, they're more prone to a "Oo, shiny new technology" mentality than others. In fact, how many techies do you know who are willing to accept a completely broken product or first-generation technology because they're excited about what it could become, or what it stands for? I would almost argue that a dumbo floor salesman is trying to deliver to a customer something that the customer is more likely to understand and be able to use.
What consumer, who aren't techies, would want those things?