6 ms·
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 suc
by Duhck 13y ago
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.
- midas007 13y agoRoles 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 http://zurb.com/article/11/the-t-in-team
- dropit_sphere 13y agoThis 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.
- deleted 13y ago[deleted]
- marktangotango 13y agoLove 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?
- dasil003 13y agoI 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.
- chris_mahan 13y agoAmen Brother Amen!
- edgarallenbro 13y agoAs 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.
- seivan 13y agoThis! I hate being treated as a code monkey.
- buckbova 13y agoThe 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.
- eikenberry 13y agoI 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 13y agoDesigning 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.
- netfire 13y agoWhat 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 13y agoSo 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.
- lgieron 13y ago> 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.
- FLUX-YOU 13y ago>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.