[Duhck]

Heres the problem I have with this entire discussion -- and this post does address it a bit -- but programming IS a creative role and needs to be treated as such.

Many organizations hire programmers as technical roles, but they are generally creatives. A lot of them are night owls, who ebb and flow between long productive stints and proverbial 'writers block'.

Many of the best developers I know have a creative desire and just writing code for 10 hours a day doesn't satiate it.

I think we need to start treating developers as creatives and giving them the processes they need to be successful and not be stressed, overworked, stretched thin, etc.

[dropit_sphere]

This will never, ever, ever happen. There is too much money, for both sides, in pretending this isn't true.

The business side has been entrusted with a lot of money, its own or someone else's. Success has already been achieved. As such, it approaches things from a mindset of risk reduction. And the absolute worst thing possible, from a risk-reduction standpoint, is creative work. It's unpredictable, you don't know when you've got an end product, and it involves dealing with workers who have egos, who often work on things you don't understand. It is unmanageable, which obviously troubles those whose job it is to manage.

The most common approach, so far, has been to ignore this scary possibility: Keep projects as low-level as possible, spread responsibility far and wide (to reduce risk, not for optimal efficiency), and keep everyone wearing business casual.

Developers are (often) in the weird position of Ozzy Osbourne and other rock stars: potheads whose potheadery became valuable. What the developers know, however, is that businesses don't really want what they have to offer. They don't want to see the full effect of a bad trip. For every Bieber who turns crappy branding to gold in the teen girl demographic, there's Joe Concept Artist who's experimenting with some new grooves, but will never catch on. For every Zuckerberg who can bang out a social network in PHP, there's some dedicated open-source hacker whose dream is to make Lisp accessible to the common man.

And yet: the money guys are offering money. Just swallow your pride, play "Stairway to Heaven"[1] at the wedding, and pretend you've never had crazy eyes when talking about homoiconicity, and the rent will be paid.

[1]Nothing against the song.

[edgarallenbro]

As a dev who also sings for a cover band, this post so completely describes my life its scary.

But, I have a bit of a different philosophy.

I think that if you really love something, you'll not only do it for free, but pay to be able to do it.

There are some people who love coding so much that you can't get them to stop. I am not one of those people. I love it enough that I can stand being at my job for 40 hours a week, and I enjoy the time I spend there.

What I really love is Rock & Roll. When I was in high school, I footed the bill for all the tickets my band couldn't sell just for the chance to play on the same stage in Hollywood that a bunch of my idols had played on.

Now I play in a band that plays 90's prog metal covers, something that someone from an 80s/90s pop cover band said no one would ever care about and that we could never get paid for.

He was wrong. People actually love us because instead of just settling for doing what paid, we did what we love, and it just so happens that there was a need for what we love. We're doing our first paid gig in a few weeks.

[dasil003]

I love this comment, but it's not the whole story. Mark Zuckerberg made his billions because he built his own company. Musicians do not necessarily need to do this (although it helps them avoid getting screwed), why does Ozzy Osbourne make bank working for other people? Because his value is readily identifiable. You can see his ticket and album sales and TV ratings right in front of you. Everyone can watch his act and evaluate it.

The problem for programmers are that their talent is extremely difficult to evaluate. The best programmers will build a system that avoided so many problems which management will never even have a clue could have happened. Meanwhile, a "rock star" might come in and bang out a prototype that looks so slick and is complete in such a short time that management thinks he is god's gift to programming even if under the hood the code is unintelligible and unmaintainable; when phase two modifications are a disaster, the blame could fall to the new programmer who is objectively much better but is saddled with a terrible technical debt that no one knew about.

It's a classic market for lemons. So management is constantly worried that they have lemons. Giving space for creativity would be much more of a possibility if it was easier to identify the programmers who deserved it.

[marcosdumay]

Well, what you are stating does reflect reality, and that sucks. Pretending otherwise does not make software development predictable, does not make developers' ego disappear, and does not make management capable of understanding what's going on.

But pretend we do. And when everything goes contrary to the expected we make sure that blame is equally distributed so that no party has a right to complain.

[marktangotango]

Love this reply, it's a summary of cold hard business reality. Seems cynical, but pragmatic and jives with everything I've witnessed. Maybe the parent is coming from a perspective of fostering the next Whatsapp, were 32 people create $16 billion+ in 'value' from within an existing business?

[mstone4]

Say one is starting a software company.

How does she go about structuring it to take this into account?

What are things which are inherently a problem and what things creating problems because it is business as usual.

[Duhck]

As someone starting a hardware company with amazing software as part of the experience, I am battling the same problem(s).

I want to hire creatives who don't need to be delegated to, and can own full cycle of tasks on their own. I have been doing tons of research in the last two months and a lot of soul searching trying to figure out precisely what makes me tick.

The truth is, every startup WANTS to hire entrepreneurial developers, but rarely let them be entrepreneurs.

In going through this process on my own, for the second time, it is clear that if I want to hire people like me, I have to treat them like I treat myself.

Trust them, give them freedom, and be willing to ask for help when necessary.

[dropit_sphere]

I knew someone was going to ask this. I certainly don't have all the answers, but I have thought about this a lot.

First: software is nearly always a dicey proposition. There are so many variables that it's just impossible to predict much about it with any regularity. The best approaches that I've seen so far accept this, and say, "Trial and error? So be it: we will do trial and error as best as it can possibly be done." YC and the lean startup model (aim low, accept that most things will fail) are good examples.

The other approach is the "tried, no error" method, which cares intensely about the past. Hiring a web developer? Portfolio first, examples of use of specific technologies, examples of specific features. Find no one who meets your exact qualifications, and proceed to either a)raise salaries a lot, and constantly (banks, hedge funds), or b) complain to Congress about a "talent shortage" (everyone else).

I think YC is the better model, and is a sort of company-less version of michaelochurch's "open allocation." The key insight is: if you want 10x engineers to ride up on their white horses and save you, you can't presume to tell them what to do. They're cars, not faster horses. Beating a car with a whip won't make it go faster---and this is a feature, not a bug.

To get the best out of developers, you have to accept that they bring risk, and manage around that, rather than blindly trying to reduce it. That's why I think Apple is really fucking smart to have a huge cash cushion like they do: with that cushion., it frees you to go for long shots. Apple is nearly riskless in its financials, and so can afford to be very risky in its product development process.

If I were starting a software company, and knew exactly what I wanted to build, I'd hire people with proven track records, pay them a bazillion dollars each, and give them zero autonomy. Or, I'd hire a bunch of college dropouts who've obssessed over some kernel of good ideas (Tufte, Hickey, FRP, ML), pay them nothing, and let them run wild (this is basically YC's business model).

If you're really serious about this---and I think it's worth it to be---I'd read everything on michaelochurch's blog. He exaggerates, has a chip on his shoulder, uses weird analogies, and has a better understanding of these issues than anyone I can think of.

[mstone4]

Thanks for pointing me to the blog. I wish he wrote fewer words while making the same points. I am guilty of the same thing.

Here is where I arrived to so far on this subject from my own reading, thinking and experience:

Each person changes over time - they want varying degrees of responsibility, working on new things, improving existing skills, who they want to work with etc. People age and with that their personal situations change as well.

Change is inevitable.

A company, group of people executing a process which provides value and receives more money than they spend to provide that value, can only survive if it can adapt to change. Both the change coming from individuals in the company and external change coming from the market.

There seem to be almost no companies ( maybe Valve, Semco and few others but I never worked in any of those ) which try to adapt to both the internal changes of their people and external changes of the market.

The current situation is this:

The rigid hierarchical companies with what Michael Church calls "Closed allocation" fail to adapt to both internal and external changes and then they eventually die. What the guy on the ribonfarm blog called - the clueless take over and the losers and sociopaths just jump ship - then the company dies.

In the startup phase, the people make the company change until market fit is achieved.

After market fit is achieved, it causes the company to resist any personal internal change so that the achieved market fit can be optimized. If there is no external change in the market the company thrives and can simply replace any "failed" individuals who no longer fit with external ones which will fit. The company puts in place new individuals to fill the rigid self perpetuating hierarchy which can still provide the same value from the market fit. The company does not care if a great female employee had a child and needs to work 4 hours a day - she is underperforming and needs to be fired for the good of the company. Bigger offices need to be leased and a small group of people who now live far away can just quit and be replaced etc. Many of the people are not happy but need to pretend they are still the right fit - they just punch in and out - "this is just a job" now.

In case the market fit does not last long but the company has made internal changes impossible - the company will die. If there is still possibility of internal change the company might adapt - but very unlikely if this happens after market fit was once achieved.

Here is my current solution to this.

Recognize that change is inevitable. Embrace it. Create a system which can adapt faster than the change that can cause either personal unhappiness or loss of market fit or profit if you will. The only way to achieve this is to let people inside the company make their own decisions for as much as they are comfortable with.

One way is democracy. People vote and tyranny of majority rules. If you do not show up to vote, whatever is voted gets selected. Every decision is put to a vote or voted to be delegated to people with a finite time limit. The limit passes and a vote needs to happen again. You can even vote for a monarchy in case of crisis - have someone make all the decisions for a period of time. The crucial thing is that any vote has a time limit and another vote is forced - to adapt to change.

Democracy depends on informed participants. No internal company information can be hidden. Salaries are an example of something that needs to be open. Salaries get chosen and budgets get voted for. You select your salary but everyone gets to vote on the budget that salary is in.

Every part of the company should have a time limit - die - and be assembled again. No group should live for more than some time limit without have a vote on who is part of it, what the budget is, what the focus is. Is this done every month, every quarter, every 6 months or a year depends on the situation. But companies need to reinvent themselves.

The time limit on votes forces the answer to "WHY". Is this group needed, did we select the right leader, right people, do we need more, do we need to change the market, product, the janitor ...

[chris_mahan]

Amen Brother Amen!

[midas007]

Roles and titles cause people to associate with and get put into boxes, and deny latent talents and dismiss insight that could very well be valid. Mgmt consultants make tons of cash repackaging internal feedback into neat, glossy deliverables by basically listening across organizational, preconceptual boundaries.

Also: T shaped people: http://zurb.com/article/11/the-t-in-team

[FLUX-YOU]

>but programming IS a creative role and needs to be treated as such.

We need to distinguish between creators and people who just implement, because there is a lot of work that doesn't involve new ideas. Complicating this is the fuzziness between the titles 'engineer' and 'programmer' and 'developer'.

Much of this just seems like growing pains for a field that's relatively new to humanity.

[lgieron]

> Many of the best developers I know have a creative desire and just writing code for 10 hours a day doesn't satiate it.

To paraphrase, many of the best X (X being developers, managers, accountants, salesmen etc.) have a creative desire and just doing their job for 10 hours a day doesn't satiate it. That's why they indulge in create activities in their free time.

[buckbova]

The majority of programming is analyzing a problem domain and applying the right design pattern. It is not creative. The longer I am at it, well over a decade now, the more this applies.

[dasil003]

Software is logic manifest, there is no limit to what can be coded. At any layer of the stack you can radically reenvision the way things are currently done in order to create a new way of doing things, and in no other creative endeavor can you so fully control the minutest detail from the smallest atom to the grandest super-structure. The reason we have design patterns is precisely because the possibilities are so wide open that we need some structure and convention to aid communication and comprehension between programmers.

If you're just churning out cookie cutter patterns you need to get a new job or side project and rediscover the magic.

[BSousa]

I'm going to go with the gp on this. I've worked as a programmer for 12+ years (and a few good more as a hobby). I've worked in various industries developing software (games, AI, QA for chemical processes, CRMs for Wine producers, Financial Institutions) and I just don't understand all this talk about programming being so special that we are 'creative' and not everyone can be a programmer talks, and all that new age crap I see exposed here in HN.

When you are learning, yes, probably it is different, but you reach a point when you see programming most things as a chore. There is no magic or unlimited possibilities. There is a goal, and you code to get there. Can we just stop with this bull crap about we being special snowflakes? Just look at your description of software: 'smallest atom to the grandest super-structure' -- Seriously?

[buckbova]

Well said.

I agree the language comes after the object, not the other way around. And speaking the same language is important.

I'm actually an architect and it does seem a bit routine for me to hammer out design specs nowadays.

[netfire]

What do you define as creativity then? You could say that the majority of writing is composing sentences with nouns and verbs if you look at it from such a low level. (or that artists are just applying specialized techniques to add to or subtract from a medium).

I suppose that you could leave the creativity in engineering to other people (designers, product managers, etc), but my experience has been that you end up a far better product when you engage developers early on in the brainstorming and product planning process and let them help decide what the product should be.

[Duhck]

So this is what I was getting at precisely. As buckbova said, programming is problem solving, and solving problems is a creative process.

If you treat developers as creatives (like you do design, etc) you get a superior product and work environment, and you involve more people in the product brain trust.

[eikenberry]

I disagree that development has come anywhere close to optimizing our design patterns. People are still coming up with better patterns for even basic CRUD and static site generation apps. Coming up with new patterns and improving existing patterns is what we do.

[buckbova]

Designing and implementing a software project is not creative. It is learned. It takes methodically analyzing requirements and designing a solution based on learned patterns through study or experience. We engineer software.

"Coming up with new patterns and improving existing patterns is what we do."

Chances are you are not "coming up with new patterns" but instead re-discovering existing patterns.

[seivan]

This!

I hate being treated as a code monkey.