The title made me think about what my answer would be. If there's one thing a programmer should know, what is it? What is the most important thing I didn't understand about programming when I started doing it?
My answer would be: that code should be seen not as a static thing, like the answer to a math problem, but as an evolving effort to figure out the right question to be the answer to; and that it should thus be written to be easy to change.
Coming up with "The" one thing a programmer should know seems too narrow a question. Kind of like "What is your favorite song?" instead of "What are some of your favorite songs?" A more interesting question might be "What things would you emphasize to someone learning to program?" Flexibility? Precision? My answer:
Every programmer should
1. Learn C / Assembly - Understand how code interacts with hardware.
2. Learn Lisp - Understand how ideas interact with code (and vice versa).
In an industrial design class I took this sort of methodology was heavily stressed using words like "divergent thinking" and "no-worry prototypes".
Generally, I believe that the super-specializing niche engineering that's popular today is best served by broadening your base rather than sharpening your technical skills to stand out in a field of pins.
I.e. marketing, ID design attitudes, learning to paint.
This is true of many industries. I have a friend who is a wonderful painter. People who see his work tend to think highly of it. Problem is, he only knows people who are "into art." He refuses to market his product. I kind of see a parallel here. Great code is great art. The next step is presenting it to people in a way which shows how it benefits them.
That's conflating marketing and advertising when they're actually two different things. Think of marketing as the social component of design.
You wouldn't start coding without at least a rudimentary spec to guide what it is you want to make, right? So why start designing your product without first identifying what and for whom it is you are designing it?
Marketing is the process of identifying the target market for your product. The "what it does" and "who it's for" part that a design needs if you're going to "build something people want".
I think you nicely describe the planning part of marketing - but you have to include the execution where you reach out to your target market. Advertising (in all it's forms) is a crucial tool of marketing.
Except that advertising isn't marketing: It's advertising. They're different things related to your business and should be handled differently.
I've run into a few companies who have painfully put an 'advertising guy' in charge of their marketing department and it's not worked well (in my limited sample). People are often great at advertising but couldn't put a decent product strategy together to save their life (or job!).
You wouldn't put your web developer or icon designer in charge of system administration or database scaling, right? Just like non-coders tend to lump everything technical together as 'computer stuff', technical folks can fall into the trap of lumping accounting, marketing, advertising, etc. into the same batch as 'business stuff'. That path leads to madness.
If I'm not misunderstanding the Y-Combinator philosophy (for lack of a better term), this is premature optimization.
Focus on making something people want, and you will then be able to find a way to persuade people to part with their money. 1 - 3 above should, I think, be highly correlated with "make something people want."
(To pre-empt charges of "appeal to authority", consider this an argument with a proper citation. :)
I don't think it is up to the ultimate consumer to become interested in what we (as developers) are doing. I think it is up to us to explain to them just what problem we are going to solve or just how we are going to save them time or money.
Thats marketing - identify the target market. Convince that market segment that they need your product and then make sure that you don't put obstacles in their way while they are trying to buy it.
I think that some of the best products will come from programmers who find audiences with whom to coevolve the product: getting into a tight feedback loop with a bright bunch of alpha or beta testers.
I like the fundamental premise of his post, but I am (metaphorically) downmodding it for presentation. His blog is beginning to look like it is hosted by INET-WEB: http://www.inet-web.com/creativeGeniusWebDevelopers.asp. Jokes aside, the danger I see here is that people might presume that when he says "marketing," he means bombarding people with gaudy images and superficial ornamentation.
Marketing vs. engineering is a common issue within a company and coming out of a failed startup - NOT marketing enough was part of the problem. The product did not sell itself, and many engineers mistakenly believe their product is simply that GREAT. It's often not (and I don't mean this negatively because engineering a GOOD product is very challenging to say the least), so be careful not to drink too much of your own kool-aid.
Historically, consumption has been driven by brand appeal which is defined by form (brand), function (product), and message (definition)... you'd be surprised how many great products have bad brands and lost in translation.
I may be one of the few hackers that loves marketing as much as I do programming. I often split my reading time between both subjects. (And personal development.)
For me, marketing is exactly like hacking code. Except that it's hacking for humans! Even though humans tend to appear inconsistent, there are patterns (just like in code!) that you can leverage.
The bottom line is this: my marketing allows me to do more of the programming I love.
"We can debug relationships, but it's always good policy to consider the people themselves to be features. People get annoyed when you try to debug them."
--Larry Wall, second State of the Onion speech
"Identifying, anticipating and satisfying customer requirements profitably."
Chartered Institute of Marketing’s definition of Marketing
nice article, though i'm not sure that's the One Thing. my one thing would be 'know your audience'. that's part message and part usability. if you're designing an app for engineers you design the ui very different than if you're designing it to allow residents of the local retirement community to self-schedule dinner deliveries.
that said:
if you're a resident in a company with a separate marketing team, it's key to speak their language -- after all, the people you're going to be marketing -to- is the marketing team. it's their job to get the message out, it's your job to be sure they know what the message is, and what it isn't. make sure you don't oversell, and let them know what would be overselling, and promote key features internally; they'll get external through the firm's marketing wing.
if you're a startup, marketing is doubly important. if you can't sell a friend on the idea of a product, you won't be able to sell the public. if your startup idea is complex, you're going to have to find a way to make it intelligible in ten seconds by picking the key features you want understood. and everyone in a startup is on the marketing team, whether they like it or not.
it's really worth it to read a book or two on marketing, if for no other reason than to get the lingo down. i've found my suggestions much better received when i could speak market-speak to the marketing team and sales team, and promote effectively to civilians. i recommend 'the culting of brands' by doug atkin as a good start.
Aim at the use, not the truth. Think about what it's supposed to do. This is helpful at all scales, from code snippet to a whole business. It's similar to finding the right question, before finding the right answer. Sometimes, it enables you to simplify dramatically.
Part of the problem is that we look at marketing as being different than the hack. However, marketing is just social hacking. A true hacker isn't confined to one realm.
You're absolutely right. In an ideal world software developers could do their art for the shear appreciation of it. But for practical reasons, we need money and other resources to do that. It only makes sense to convince others how valuable the craft is to them so that we are empowered to do it.
If smart engineers would just look at it as simply another problem to be solved -- people hacking -- we'd be set.
My answer would be: that code should be seen not as a static thing, like the answer to a math problem, but as an evolving effort to figure out the right question to be the answer to; and that it should thus be written to be easy to change.