Take pride or fuck it
robertheaton.com
robertheaton.com
If you're writing some deep enterprise level back-end stuff that is going to be integrated in a large, expensive system, obviously it really is worthwhile to do it right.
If you're cranking out another piece of shit marketing website, or even better, anything app or mobile related, no matter how much planning and testing and pride you put in to it, it is almost always completely worthless in a couple years.
Everything is changing so fast right now, the platform, device, language, database, etc, may not even exist in 5 years. 5 years! That's a hell of a depreciation schedule for a $200k project.
I really learned not to invest much time and finesse into those kinds of projects. When i was younger i was thinking "oh, someone may look at the code, keep it clean...". Nearly 10 Years later and dozens of projects later: Only 5% of my code ever got even a second glance or had to be changed...
If your attitude is that reading code is a lost cause, you'll create a bunch of shitty, illegible code.
People forget that outside of the corporate world, there actually is code that people (a) enjoy reading, and (b) write with the intention of making it comprehensible.
On the other hand, that first product I worked on is still in service, over 15 years later.
Obviously, this doesn't apply to life saving (or threatening) software like medical, defense, embedded systems etc.
Making it technically good is a way of making it interesting and something to be proud of. You could also make something that is yours. You could also make something that is really actually important. Without any of those outlets people will just hate their jobs and only live for their time off.
There is an impedance mismatch between the way computers work and the way the real world works.
Software works in clear conditionals, numbers without any uncertainties, events that flow deterministically based on relatively simple rules.
The real world works in probabilities, half truths, imprecise numbers, special cases, partial information, irrational actors and deliberate rule breakers.
When you start writing a new piece of software, at first you tackle the most common cases of the real world. At this point it is possible to write clean code and well defined abstractions. However, eventually you are going to get users that will find that your software is too simplistic and doesn't take into account common sense exceptions, doesn't give them enough flexibility to deal with partial information and doesn't allow them to act according to unwritten exceptions to the rules. You have two choices. Either refuse to bend your software to the real world to keep code simplicity or start coding in the exceptions that your users desperately want.
Computers don't understand common sense so you have to translate all these exceptions into well defined rules and heuristics even though this does not reflect how things work in reality. Because computers don't think probabilistically, these heuristic tend to be numerous and complexe and difficult to deal with.
The main jobs of programmers in my opinion, is to manage this complexity so that their programs don't become too unpredictable when the thousands of exceptions interact together in unexpected ways. It's quite the balancing act but I think the best developers are those that don't back down and are able to face these types of problems. Sometimes this means refactoring some exceptions out of the system, or moving it somewhere where it doesn't cause unwanted interactions but sometimes it means leaving it in and managing it as best as you can so that your software can deal with the world as ambiguous and fuzzy as it is. A developer that ignores the fuzziness of the world in order to write clean code, is naïve and ineffective in my opinion.
It doesn't mean that you should write crapy code, it just means that sometimes you have to in order to meet the exceptions in the wild.
Then I realized that people take pride in different dimensions of their work. Perhaps for one person it's well-factored code, for another person it might be design and user experience and overall polish, for another person it might be the ultimate effect of the product being built on the customers (or on the business). And even on each of these there is infinite room to give a shit or not about different components of them.
All too often, being obsessive about code cleanliness is a type of bikeshedding among geeks who have gone so far down the rabbit hole that they can't engage meaningfully with the world through anything but code. Or have been so disempowered through years of cruddy jobs and sitting at the kids' table that they haven't reason to try.
It's a hard balance to strike, because there certainly have been projects where people couldn't move forward or feel pride in anything because the code was so messy. But in these situations I've found it's best to try to see the big picture and pick my battles. Code quality is only important in service to other goals.
This.
Sometimes it's really hard to tell when you're shaving a yak instead of fixing broken windows. What are some ways to tell you're doing the wrong one?
With the "weekend project" idea it seems that we easily forget how real jobs often require time and struggle, even for smart people.
"All too often"? Is it? I hear this all the time and very very rarely actually see it. It definitely exists, but our community seems to treat this unicorn as if it's the major issue affecting productivity.
Way way more often I see the opposite. "Just ship it! Lean startup!" a month ago leads to the inability to ship now because every part of the code you touch to add a new feature results in everything breaking. And of course there's no unit tests or any kind of documentation or even agreement among those working on it regarding what responsibilities each part of your system has. It inevitably results in the dreaded "big rewrite", if you haven't fallen behind your competitors enough at this point and are still in business.
Like you say, it's a balance and a hard one but I'm getting more and more convinced that this false consensus results in bad advice, especially when non-technical people start throwing around "just ship" and "move fast and break things" without even knowing there is a balance.
There is also absolutely no context to this lean advice that this balance is completely different for different types of programming. You will never get a good search engine written by "moving fast and breaking things", you're going to have to do some architecture/design work before you start writing code. But if you are setting up a wordpress blog to do affiliate marketing then by all means just fucking ship it.
Maybe I'm living in a bubble that's very different from everywhere else? Where people went too far with good advice? If that's the case then I want out! I will hire some obsessive bike shedders and teach them to consider time as an important factor. Way easier than trying to retrain people who think that loose coupling or not putting every method you can think of into one monster class is "obsessive perfectionism".
I also work in 2 modes: "1. Make it perfect." and "2. Just get it done and hope I never see it again."
I used to do everything in Mode 1 and took great pride in my work. Now I use this logic:
if (LowLevelCode) or (VeryImportantAppForCustomer) mode 1 else mode 2
Funny, the longer we build software, the more we rationalize and the smarter and lazier we get.
Pay day and beer, ususally on the same day.
(This is not a snarky answer, but the truth, for me and many of my contemporaries. The internal conflicts caused by the irrationality of others can eat you alive, but only if you let them. OTOH, whenever I get paid, I realize how much harder my father and grandfathers worked for so much less and thank my lucky stars. I'm not saying that this is ideal, but it works. Another great strategy is to go home and build something for myself in Mode 1.)
1. Don't link perfection and pride so strongly. Find ways to be proud of other things about your work besides "perfection." Many of us are perfectionists or recovering perfectionists, and we aren't sure what's ok to be proud of besides an A+ or brushing against some platonic ideal. Pride is individual and has to do with our identity, so find what resonates with you. Try being proud of: just doing the work -- productivity, reliability, consistency, quantity; particular skills or expertise; specific aspects of quality that you personally value; the end product and the good it will do or who it will please. I draw inspiration from creative professionals (writers, artists, performers) who have strong process and show up each day to face the blank page. I like to create delightful and visually beautiful things. If you are too egoistic about your work or your job just isn't a good fit for the kind of work you are proud to do, you may need to find another job, but usually you can go far by getting in touch with what things that make you feel good about the work you do and desensitizing yourself to "flaws" by putting them in perspective. "I make perfect things" is a lame identity; dig out a better sentence for yourself.
2. "Just get it done" and then do look at it ever again! Be comfortable writing first drafts. Start early and revise. Or, save some improvements for the next release. Be aware of acceptable flaws in your software without having to compulsively fix them.
If you are working on a team, try to align your goals with theirs and accept the constraints that come from working with other people. It's also ok to have your own goals that no one else shares or supports. Expect resistance, but if you believe in it and can muster the confidence and courage, do it anyway, and people will respect you later.
Currently, I believe that the primary cause of this mode1/mode2 divide is perfectionism fueled by fear and internal resistance. As perfectionists, often the level or type of "quality" we insist on, which may be contrary to the expectations of all around us, just isn't reasonable, or isn't compatible with shipping on time or achieving our greater personal or professional goals. Or, it may be an achievable level of quality for us, but we just aren't good at sitting down and achieving it. We put off the tough design questions or stifle the very creativity we need to meet our own standard.
Another random tip: Find small ways to be creative in your work even if they don't matter to anyone else.
When all else fails, invoke the "it's just a job" frame as necessary, have a beer and don't worry about it. :)
Earlier, before I've had the experience I have now, I would have called this notion misguided; today, I'm not so sure. Don't get me wrong I hate cutting corners just as much as the next guy, but if you have a budget to work with, and a deadline, you simply can't write perfect code. It just has to "work" because that's what the client cares about... obviously. And unfortunately.
I still don't like it.
This. I hear "Lean Startup" way too often as an excuse to do something shit. I'm so over it.
Doing something shit is easy.
Every situation is different but i'm generally of the opinion that you should do the absolute minimum required to achieve your objective but just do it well. If your trying to get to market asap so you don't die a horrible death i'll give you a temporary pass on the quality... unless quality is one of your core value propositions.
The way I used to think about development was that there were separate phases: building, debugging, then launching, then you stop working on it because it's "done." Then, I suppose, you go on vacation and sip Mai Tai's on the beach.
The thing is, once you get rid of the "done" phase, your whole perspective changes. The other three phases (building, debugging, launching) get mixed together in a blender. Suddenly, any time you hack something, it's okay because you're going to fix/change/refactor it later. It's all part of one big growing, changing, process -- a process that actually fits with the literal meaning of the term "development."
So it's not about pride anymore for me, it's about humility. These days, when I build something, I start off hacking something together in the quickest way possible, no matter how ugly. Then I just keep iterating, refactoring, fixing, cleaning: improving, improving, improving. So there is never a moment when you proudly show off a gleaming, fancy product and say "look, I'm done!" There's always something that works, something that doesn't -- something that needs to be completely rewritten, something that looks good and you haven't touched in months (or years).
The great thing about doing this is that it's a good way to keep yourself from being an "architecture astronaut." If you start with a hack and build refactoring into your process from the very beginning, you'll never build out more architecture than you need, because every time you use a design pattern it will be a direct response to a real need, not an imagined future need.
To conclude, I'll leave you with this quote from Walt Whitman, talking about the "deathbed edition" of "Leaves of Grass" -- a book he revised nine times during his life, which grew from 12 poems to 400 during his lifetime.
"L. of G. at last complete—after 33 y'rs of hackling at it, all times & moods of my life, fair weather & foul, all parts of the land, and peace & war, young & old"
Not sure what "hackling" means, but it sure sounds a lot like hacking!
So you have to look at how much payoff you're getting from maintainable code versus shipping late. I would say that how to manage this tradeoff depends on the type of software being developed - If you're creating throwaway apps for the app stores then shipping fast is probably a more important consideration than having a maintainable codebase. If you're writing banking software for the enterprise the balance probably tips in favor of maintainable code.
You also have to take into account the constantly shifting goalposts in software development. That class you spent all day refactoring gets thrown out tomorrow.
I'm not a programmer (at least, I'm a very beginning one), so maybe someone can clue me in: Are all best practices equally destructive if you don't follow them? Or are there best practices which can be neglected?
I'd expect that the best practices being neglected would be differently relevant to different projects, types of application, customers, etc. Would it be productive to modify the discussions of "best practices" by talking about under which context those practices are necessary or unnecessary?
1. Business data should be stored in a proper relational database such as Postgres, with a well-normalized schema. This is critical; if you don't do it before the first day in production, inconsistent data will accrue and then it's too late to solve your problems just by fixing your code.
2. Your code should be well formatted, properly indented, with variable names that are informative but not too long. This will end up being important, but if you neglect it initially, you can fix it up later, so it doesn't have to be right upfront.
3. Your code should be commented where appropriate. This is good to have, but if you neglect it initially, you can add comments later, and even if you never get around to that, you can probably work well enough without them, so if you find you don't have time to write comments, don't sweat it.
For any practice whatsoever, you can find people who will insist it's do-or-die critical (I've seen people insist uncommented code needs to die in a fire along with its authors),so you have to use your judgment to distinguish between things where you have to make a stand and things you can let slip.
On the other hand, there are plenty of people out there who are somewhat paralyzed by the completely open and undefined possibilities of a project not yet started, whose spirits soar at the opportunity to take something mediocre and really make it shine.
The trick is to pair with someone of the opposite type, and work together to make truly awesome stuff, and keep each other honest and not lazy. I've done this many times over my career.
Grow up, deal with it. Delivering bad news is part of many jobs, and programmers shouldn't expect to be exempt.
It's your choice whether or not you compromise your code. Sometimes you'll agree that it's worth it (shipping means $$$ the company desperately needs), sometimes saying no (because you know the consequences won't be worth it) will initially make people unhappy/disappointed/angry.
You can't please everyone all the time, and if you make pleasing your boss your highest priority, well, that's the price you pay.
While you and I know that refactoring is the right thing to do, the customer/manager isn't going to say "by all means, delay completion of the project in pursuit of improvements to parts of the system that only you have to deal with". They don't see/understand the code so naturally they don't care about its state.
[note] Obviously this is a blanket statement but it's been applicable to me and I'm sure others have experienced similar.
If the guy who made my lunch sandwich put as much pride and care into his product as we all want to, which lasts about as long as the average modern software application, it would cost $50 and I wouldn't want to buy it.
I think that's a false dichotomy. There's the $6 Subway option and the hypothetical $50 perfectionist option, but you can also get a really amazing sandwich near here for $9. They make something they're proud of, and it costs more than Subway, but it's worth it.
I agree that the typical Make-The-Boss-Go-Away Development Methodology is suboptimal. The only reason software engineers even come up with those silly estimates (which are pure bullshit, and lead to dashed expectations) is to make bosses go away so they can get back to work.
That pattern of behavior isn't what's best for companies.
On the other hand, this guy is a hired company cop that can turn off your income and fuck up your resume. You have no moral responsibility for anything but what works for you. If you have the rare good boss and a positive relationship, then deliver bad news early and be honest. If you have the typical extortionist thug ("serve my career goals or get out") then Make-The-Boss-Go-Away Development may not be the best strategy, but it's certainly morally acceptable.
What constitutes quality is context dependent - a quality criteria that is meaningful on a large project that will be used for a long time (for example, one that improves maintainability) is not necessarily meaningful on a throw away script that will not conceivably be reused.
Too many people are influenced by fashion when it comes to evaluating quality. Some things called 'best practices' will provide no organisational benefit, and might increase the cost without any corresponding gain.
Slogans like 'take pride or fuck it' probably do more harm than good - what you should do is think rationally about what the appropriate quality criteria are for a given project, keeping focused on the continuing 'business' justification for the project and all the criteria, and aim to produce something that lives up to those quality criteria. By focusing on what is optimal for your goals, you avoid premature quality optimisation / over-engineering.
The opposite is also true: if your endeavor did succeed, you'll probably remember the journey with the sense of "of course deep inside I always knew this was going to be great" even if in fact you didn't believe in what you were doing.
In my case, sometimes, another team fucks up, they cannot ship the product on time and I have to join to help them. As I have to deal with bad codes, bad practices, short deadlines and a product that I don't have any interest in, I often become a zombie and get it done as fast as possible and hope I would never have anything to do with it again.
However, if I truly care about the project or have a project that has been very well designed so far, I always find myself going out of my way to ensure I will be proud of it when looking back.
look at softpanorama regarding lots of years, it just gets frustrating.
I used to take style comments from reviewers seriously, until I saw the code they had submitted that got them promoted.
There have been occasions I fall in love with a particular solution because it was so elegant and I just have this urge to tell everyone about it.
But there have also been the opposite...
Ok, to be serious... I perceive a dissonance here.
On one hand, we're essentially a degraded tribe. Most software engineers work for managers. We're not a profession, we don't pick our tools, and most of us work on uninspiring bullshit and are subjected to Brownian Management that has one team digging holes and another filling them in.
Management has its place, but in most companies it's a class of intermediate extortionist thugs who keep talent down: you support my career goals, or you're gone yesterday. Only the most progressive companies (Valve, Github) trust engineers to work directly for the company. No wonder our industry is so fucked.
On the other hand, the fact that Yahoo bought a small team of high-schoolers for $30 million and canned the product means that there is a lot of value in what we do. As engineers, we have a lot of muscle. We're good at something for which the world has almost infinite demand (not "programming" only, but the more abstract talent of solving problems and improving shit.) We're just terrible, as a class, at negotiation. We need to get better. We also have a tendency to want to put our heads down and ignore "the boring business stuff", then we get pissed when non-technical executives drink our autonomy milkshake. We need to stop that, too.
And how can you have a symbiotic guidance/mentoring relationship when most devs consider management to be just about the worst scum on the planet? Relationships are a two-way street.
Well, management is a class of work, not necessarily an entitled set of elevated people. The way you do it is to have a Valve or Github structure (self-executive culture) where everyone is responsible for keeping focus on business goals and the administrative work of the company. So now, management is everyone's job. Don't like how the company's being run? Go fucking do something about it. You're part of the management. Now act like it.
I don't have much love for the idea of a professional executive, though. When you have people whose job it is to Make Decisions and nothing else, then you end up with a small group of people who feel entitled to make their ideas unassailable. That's horrible. The company loses the ability to shred up a bad idea without attacking the person. No idea should be unassailable, and no one should be in the position where the job description is to Make Decisions and there's no participation in the actual work.
By the way, I don't think "managers" are "the worst scum on the planet". Many are fine human beings. Nazis and serial killers and date-raping HS/college alpha types are "the worst scum on the planet", not managers. I think management is a job that most companies structure extremely poorly.
But it all goes back to feeling empowered, and its up to your horizontal managers to give you that breathing room.
I basically agree with that, but on the flip side, I'm not convinced that management has no role. Self-organization sounds good, and it certainly works in some systems, for some value of "works". The question I have is, when the system is designed to achieve a very specific end - "maximize return on invested capital" - can total self-organization do that?
I also think it's a misnomer to suggest that executives do nothing but "make decisions". Good executives aren't just sitting ivory towers mandating things by fiat, they are conduits and coordinators. They proactively seek out information, identify problems, bottlenecks, etc. and work to coordinate efforts between all involved parties to mediate things.
I think management is a job that most companies structure extremely poorly.
Now that I agree with.
Don't get me wrong, I'm all for a very flat organizational structure, empowered employees, shared purpose and self-organization. But I think specialization of labor has a role to play as well, and I think there is some value in traditional management.
All of that said, I would love an opportunity to go visit Valve or the W.L. Gore and spend some time observing how things work there. When they day comes that we can grow Fogbeam Labs and have start having to deal with more people, I am very much intrigued by trying to keep management as minimal as possible.
"Maximize return on invested capital" is a horrible goal. It's not even the real goal of most investors. Retirees have most of their money in bonds-- stock gives better returns, and exotic vehicles do better than that (on average)-- but at that age, they don't want the risk. Investment isn't about "maximizing returns". It's about managing risk. Applying calculus and basic knowledge of derivative securities, I can come up with an investment strategy that has an EV of +50% on one year... but that has a good chance of leaving you utterly hosed. (Load up on beta using out-of-the-money call options.)
Also, the claim that CEOs are legally required to operate in short-term shareholder interest is a common misconception, but it's not true. There is no such law. CEOs aren't allowed to make decisions to the advantage of their personal financial benefit while hurting the company (that's called "stealing") and if they use dishonest means, they can go to jail. But a CEO who prioritizes a subjective health concern (sustainability, ethical business, fairness in compensation) isn't doing anything illegal. It's the CEO who gets caught embezzling funds who goes to jail, not the one who increases salaries by 10% to improve morale.
Now, there are a lot of sociopathic executives who use this "legal obligation" (to maximize short-term shareholder returns) to justify a lot of selfish and questionable things (that benefit their bosses, and thus them) but the truth about it is that it doesn't exist. It's an excuse. Classic negotiation tactic: It's Not Up To Me.
Healthier companies, I would argue, are less prone to downside-heavy but often invisible (non-financial) risks. If everyone feels micromanaged, overworked, and underpaid, then you're at risk of external "poachers" if the job market improves. This doesn't show up on a balance sheet, but it's pretty critical.
I've written a lot about these issues here: http://michaelochurch.wordpress.com/2013/03/26/gervais-macle...
Managers are an internal police force hired to protect the interests of owners against theft (or adverse negotiation, overcompensation, etc.) by employees. The difference is that we need police in society. Companies don't need a separate police force; ideally, they're self-policing.
I wrote about these incentive and principal-agent problems in detail: http://michaelochurch.wordpress.com/2013/03/26/gervais-macle... . Essentially, there need be no conflict of interest between employees and investors/owners. In fact, employees are investors-- of time.
Like police, most managers (by numbers) are good people but the dirty ones are really awful-- and usually get rich. In the corporate context, this is because they get so good at taking credit (the actual A players fear them) that they look like high-performers and rise quickly.
What happens in the worst companies is that owners are protected against low-level workers but robbed by the managers. They fall down hard on the "who will police the police?" question.
A small group of people, if there's full transparency about what's going on and how proceeds are divided, can be self-policing. Rick Grimes is no longer the sheriff of his group of ~10 people. They all take on the "police work"; even children. Yet cities of 4 million and nations of 100+ million need a specific police force. They can't do without them. At that scale, it's a necessary job.
By the time your company needs a police force-- it's spending a substantial fraction of its budget protecting against theft (mainly, "time theft" by an employee who favors personal interests)-- it should be scaled back and hiring made more selective, with transparency improved to make sure incentives are aligned and behavior is above-board and ethical. Cities and nations need cops because they don't fully control who gets in (or is born there); small companies aren't the same way and can be self-policing.
This is only workable if you're a startup that happens to have one of these rare people as founders and isn't planning on growing too much, or your company is among the most desirable place in the world to work.
The way it usually winds up working in practice is that you either promote your top tech people to their level of incompetence where they unhappily fail on the management side, or you hire competent managers who have to enforce a rather low tech competence ceiling in order to fit their command and control style.
Most developers aren't arrogant prima donnas, they want to learn from people who know more than them, but expecting someone to be able to mentor a projects' worth of people while also handling the regular management duties (hiring, delegation, oversight, resource allocation, communication with the execs, endless HR paperwork...) is setting someone up to fail.
You're right all the way, IMO. And that's sad.
First Quadrant (interesting/essential) is never an issue to allocate. In the ideal world, all work would be 1st quadrant. It's important and good for morale.
Second Quadrant (undesirable/essential) is what companies have to do. It's a morale liability, but too important not to get it done.
Third Quadrant (interesting/discretionary) is what one hopes will be achieved with slack in the schedule. Ideally, it'll pay off in the long term. It's good for morale, but not relevant to the immediate path-of-execution.
Fourth Quadrant (undesirable/discretionary) is the junk that should never exist.
Originally I used "category" rather than "quadrant", but quadrant implies a certain visualization, even if the numbering is different.
no matter which profession you pick there will be administrators, managers, or partners who will be looking to exploit workers willing to take the shit rolling downhill
and in any profession there will be workers who are adept at standing up for themselves and not taking the shit rolling down hill
at somepoint you have to stop viewing your self as a replaceable cog, and stop letting others view you as a replaceable cog, and realize that if the people you work for a view you as such, you're better off working somewhere else anyway
It's how I make my living. I'm very good at being a replaceable cog. I'm very quick when becoming a replaceable cog, and I get paid precisely because I can slot in, get things done and then leave again. This is also how I like to work - I'm constantly immersed in new systems, learning how they work and hopefully helping to improve the underlying stuff as well as churn out functionality.
This doesn't mean I take 'shit rolling downhill' from management, but it does mean that I am there to facilitate them, their ideas and their projects rather than make good stuff on their own. I play my part as best I can, advising them what to do better but ultimately deferring to them even when I know what they're doing is wrong, because they are the customer.
Hopefully (as mentioned upthread) I'll someday be able to cobble together all the wrong into a coherent set of thoughts and either become the best dev manager ever or start selling consultancy services.
It's a difficult situation to try and stand up to an employer who is telling you to do one thing when you know it's the worst possible decision they can make. It's a great idea to think we should stand up for our knowledge better, but chances are the arrogance and determination of the employer is going to stomp you right back into place, or even worse, out of a job.
If you're in a position to comfortably take a stand in this fashion, congratulations, you must be very well off. I consider myself lucky to have a boss that listens and understands when we have a concern. That doesn't mean the rest of the company does, but to have one layer between me and the real decision makers that will listen to what I have to say and protect my job in the process is a blessing.
That said, until developers are the ones with all the cash and say-so, it's going to be difficult to take this stand.
The thing I've realized as I've gotten older and more experienced is this: The worst technical decision is not always the worst business decision. Let's over-simplify a bit and go with the notion that "the point of a business is to make money, and a highly optimized business is one that generates the maximum return on invested capital". Given that, the optimization that leads to the best ROIC might not be the most elegant technical solution or the cleanest, most maintainable, well-engineered bit of code.
Of course there is some correlation, and I'd definitely argue that many companies do make short-sighted technical decisions that are also bad business decisions. But we have to understand that the business does not (usually) exist for the primary purpose of creating beautiful, elegant, marvellous technical artifacts that will be revered for centuries.
They hear the people who pay them money over the people they pay money to all day.
Well, yeah... if the customers aren't paying them money, there won't be any money to pay us.
It's a great idea to think we should stand up for our knowledge better, but chances are the arrogance and determination of the employer is going to stomp you right back into place, or even worse, out of a job.
My experience has been that leaders at most organizations are quite willing to listen to your concerns, and aren't going to "stomp you out of a job" for stating a concern and giving your opinion. But when we (techies) start our "holier than thou, we are the techno wizards and you are all brainless sheep" routine, then yeah, what do you expect?
This "respect" thing has to be a two way street. And we (techies) as long as we desire to have paying jobs with for-profit companies as our outlet for our desire to build technology, must, must start doing a better job of understanding business, and the concerns of the "business side of the house". Of course a manager is going to get frustrated when one of us comes to him carrying on about the need to switch to functional programming in Erlang, but without any ability to articulate what the business case is.
That doesn't mean the rest of the company does, but to have one layer between me and the real decision makers that will listen to what I have to say and protect my job in the process is a blessing.
Here's a thought: learn to speak the language of the "real decision makers" and learn more about their problems, concerns, issues, etc. to the point that you can talk with them directly and have meaningful, productive conversations that span the lines between "the business" and "the technology". Ideally they would meet you halfway, but if they don't... well, what can ya do?
Yes, exactly. I should have said something about that in my little mini-rant above, but I ran out of time or lost my train of thought. That's it in a nutshell though... be able to talk about the relative advantages and disadvantages of various options, and - more specifically - do so in the context of what serves the long-term interests of the business.
If you hire a pollution expert, that person's job is to provide knowledge about pollution. It is counterproductive to completely silence and fire that expert for doing their job. If it happens that you take money from people who like pollution, that doesn't mean those people become authorities on pollution.
Unfortunately this stuff DOES happen, and there IS an asymmetry of respect - whether you recognize it or not - and you don't propose any real solution. You just throw it all back on the developer. It's all the fault of stupid, bad developers who do not respect business enough. No, sorry, that is simply not true.
The pollution expert's job isn't to pretend to be a business analyst, or flatter you. If you propose to do something which will hurt the workers or cost more in cleanup than production, it isn't the pollution specialist's job to shut up when it might make money. It is definitely their job to tell you when pollution is likely to affect the real outcomes of your enterprises. And it's definitely your job to listen when it matters. Ignore the experts at the peril of yourself and your clients.
If they are sounding off about things with no relevance like whether we are using Erlang just for the sake of it, they are not functioning as experts. But that isn't an excuse for silencing experts or characterizing people who complain about expert-silencing as holier-than-thou techno wizards who think everyone else is brainless sheep.
There is a division of labor. Maybe you are a brainless sheep about pollution. Maybe not. But the point of informing you is not to hurt your ego and it is not justified to suppress and fire experts in order to protect your ego or advance your personal career.
If you hire a pollution expert, they do their job, and you suppress their opinion - you are doing it wrong.
The point is that there are plenty of developers who are SO concerned with technical matters to the exclusion of all else that they make it difficult for business leaders to interact with them, especially when they are the ones perpetuating negative stereotypes about business leaders. Now obviously I'm not referring to all developers, but if you can't acknowledge the existence, even prevalence, of the mindset I am referring to, I would argue that you are very naive or have led a very sheltered life.
Unfortunately this stuff DOES happen, and there IS an asymmetry of respect - whether you recognize it or not - and you don't propose any real solution. You just throw it all back on the developer. It's all the fault of stupid, bad developers who do not respect business enough. No, sorry, that is simply not true.
Your hypothetical "pollution expert" is more likely to be a consultant hired to solve a short-term problem, from what I've seen, so that's not exactly an apples to apples comparison. Nonetheless, the lack of willingness of (some) developers to be proactive and make an effort to understand more about the businesses they work in, and their lack of desire to learn to communicate with the business leaders in their language, IS damaging. And I'm not saying anything like "It's all the fault of stupid, bad developers..." That's either hyperbole on your part, of you totally misunderstood what I said. FFS, I am a developer, and I hate that so many business people are as clueless as they are about technology. Nonetheless, I stand by what I said before:
If WE want business to be out outlet for creative expression (as opposed to working as pure artisans funded by patrons or some other alternative) then there are compromises we have to be willing to make.
But that isn't an excuse for silencing experts or characterizing people who complain about expert-silencing as holier-than-thou techno wizards who think everyone else is brainless sheep.
I'm not sure where you got the idea that I'm in favor of silencing experts, but that's totally wrong. I would never advocate that. But, again, the very best decision from one specific point of view might not be the best possible decision from the point of view of the businesses as a whole.
'two way street'
How is insisting that communications and respect requires a "two way street" anything negative??
In short, you seem to be all about developers being wrong and managers being right here and it comes across as condescending.
I never said that managers are always right, or that developers are always wrong. And if I am being condescending, it's towards one certain class of developers (of which I used to be one) - the ones who are "holier than thou" and who don't understand that the technical artifacts they are building are not an end unto themselves and who walk around insulting the executives for being "brainless suits" and who don't want to hear anything about how a business actually works. To those people, I offer no apology whatsoever, and would add "grow the fuck up".
At work, there seems to be an accurate square-root metaphor (probably unrelated to actual Brownian motion) in the use of resources and time. You really get stuff done in 3 hours out of your 9-hour day; the other 6 are meetings and face time and bullshit. 2 days out of your work week see real, macroscopic progress; 3 are wasted. Seven of your 49 work-weeks are on projects that actually get used, and the other 42 are on manager-blessed busywork. Six years of your career end up actually mattering; the other 30 are wasted on jobs that go nowhere. So you get 3 h/d * 2 d/w * 7 w/y * 6 y = 252 hours per career that really mean something. Better make the fuckers count.
That's depressing and probably not that accurate. If you can take charge of your time and responsibility for your progress, you can do a lot better.
Brownian Management is the pointless drifting about that goes on when no one has any sense of direction. It generates the world where (as they say in many businesses) 90% of work is counteracting negative side effects of other work.
That's like 31 8-hour days. I'm trying to imagine what I could get done if I had a personal assistant to manage all the non-technical bullshit, and a month's supply of speed.
They have no direction of their own.
Wow. In three sentences you likened management to the mafia, said they were only concerned about themselves, complained about lack of trust towards engineers, then said our industry is fucked, all without a hint of irony. It sounds like you want everyone to trust you for your genius talent but you don't feel you should have to extend any trust the other way. That's now how trust or human interaction works, and the whole statement makes you come off like an immature prima donna. You're making us look bad and I'm almost embarrassed to share the same job title as you.
I see management more like political parties than mafia. But they are more or less the same I guess :-).
I've seen companies where 90% of the managers were decent people, and companies where zero percent were decent people. It seems to average about 70, but that bad 30 percent can do a lot of harm.
==Takes one to know one?
Without a hint of irony.
All of his comments come with a deep disdain for management and a grand philosophy on programming in the abstract. At least the chip on his shoulder for Google wasn't around for this comment.
If you are good at negotiation, you'll get past that.
Negotiation isn't just about the meeting and the table. Everything you do for years before even meeting each other is part of it.
Sell a vision of a positive outcome: by retaining you they'll work with someone cool and they'll get lots of money and respect out of the association. Don't sell a close match on resume filters.
It's possible that you won't be able to make the case, and that's okay. They can keep looking for someone willing to take their opening offer.
(*or any other recommended book)
There is also a difference, in a commerce transaction the best outcome is when both parties think that they got a good deal, how the parties feel about each other only matters in as much as it will impact future potential transactions (i.e. if the buyer thinks that the seller is a sucker and charged too little then as long as the seller is happy with the price the only consequence is likely in the future if the buyer tries to take advantage of the seller)
In a transaction that aims to start a long term relationship (i.e. employment!) ideally neither side should carry negative sentiment from the negotiation. Likely you are negotiating with an HR dept or recruiter who won't take it personally, that makes it easier for the applicant to be a little "harder", the reverse doesn't apply, if the company plays hard-ball it can leave a lingering sense of resentment in a new employee (who should otherwise be entering a honeymoon period)
The last time I changed companies I took a small pay cut (bottom line, headline pay was slightly more, but benefits were noticeably worse) - it grated for a long time, even though the eventual outcome was good (acquihire)
Having been on the other side of the hiring process, I doubt it. Finding good candidates is hard, by the time that you are making an offer you are already much more invested in the candidate as a potential employee than you are in other candidates to whom you have not yet made an offer.
But, (there's always a but!) if you are happy working there, and that's the result you wanted and needed this this was a good outcome for you. Congratulations!
One year later, it's only about as hard as programming, but I'm now on to a new thing that's harder than anything I've done before: managing.
All those "business people" should work for the companies talent, not the other way around.
No, let them stay. They have important skills (what, you want to sell rather than right code? by all means) and most of the are fine people. Just don't give them 100% of the power. They work for us, we work for them. Keep it symbiotic rather than parasitic.
It's not really clear to me what market forces push engineering companies to be a somewhat odd amalgam of "idea people" and "execution people." If I've got an interesting idea, why do I need to hire a bunch of engineers? Why can't I just hire a firm of highly experienced engineers who can execute my product. On the idea side that would free idea people from the burden of HR, and on the execution side that would allow highly skilled engineering teams to build up valuable institutional knowledge that could be passed down to new recruits in a structured way, instead of all that collective experience scattering to the winds every time some startup fails and the engineers head to other projects.
Not sure that last part follows. To me, your point reads like a validation of the Fundamental Attribution Error, that there's a lot of value in being lucky.
http://dilbert.com/blog/entry/the_managementfree_organizatio...
The one quote to deal with that is simple: "A professional is someone who can do his best job even when he doesn't feel like it"
That's what I keep in mind when I have to work in that special Java/C# + ORM / (N)Hibernate + XML + SQL kind of development hell.
:-/
There isn't necessarily anything inherently wrong with Java, C#, ORMs, XML, or SQL. All are pretty useful ways to solve certain classes of problems, taken on their own.
That said, there are definitely "development hell" projects that feature all of those things, but I believe you can have "development hell" in any language, using any libraries, and any persistence technology.
And anyway, if you think writing C# or Java code is bad, trying writing RPG/400[1] using SEU[2] on an AS/400[3] sometime. That stuff'll leave you shuddering and sweating in your sleep, and walking around with a blank stare on your face, drooling and mumblng "Ia! Cthulhu Fthagn! Ph'nglui mglw'nfah Cthulhu R'lyeh wgah'nagl fhtagn, %!@ ^^&!@(, (#!^H NOCARRIER".
[1]: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index....
[2]: http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?t...
Which means Android and Windows are kind of following a path similar to a mainframe OS. Interesting for language geeks.
Anyway I haven't touched one since 1994.
Developers in general would probably be well served to do a better job of acknowledging our own history and maintaining more awareness/context regarding what has come before.
It's a warm and fuzzy quote, but humans don't work this way. If we're not sufficiently motivated, no force on earth is going to allow us to do our "best job".
A good manager knows this situation and can help their team through it. Sadly, there really aren't many good managers out there at all.
But the appeal of the quote comes from that magic word "professional," and the respect, autonomy, and pay associated with it. Promising that the Respect and Pay Fairy will anoint you a Professional once you become the very best FactoryBeanListenerObject builder in the bowels of Enterprise doesn't tell the whole story.
The word has suffered the same fate C.S. Lewis ascribed to "gentlemen" and "Christian"
"When a word ceases to be a term of description and becomes merely a term of praise, it no longer tells you facts about the object: it only tells you about the speaker’s attitude to that object. (A ‘nice’ meal only means a meal the speaker likes.) A gentleman, once it has been spiritualised and refined out of its old coarse, objective sense, means hardly more than a man whom the speaker likes. As a result, gentleman is now a useless word."
For more on this topic, I highly recommend michaelochurch's November essay on what a true profession of programming might look like.