Sorry, Digital Ad Exec, I Probably Don’t Want To Work For You
typicalprogrammer.com
typicalprogrammer.com
I'm sure you have some caveats to that - like learning to read, and doing basic arithmetic. And that's the issue here. It's the 'curse of knowledge' again.
For anybody that doesn't already know how, "learning to program" mostly means learning a bit more about how computers work. And universal computer literacy would be a great thing, much as universal literacy has been.
I'm guessing that some people thought "if everybody can read and write, then we'll all become educated and be able to write great novels". Unsurprisingly, that didn't happen, but other huge benefits were accrued. People could go to the library and check whether that thing they were told was actually true. They had a cheap and simple means of permanently storing and retrieving information. Health, legal, and financial advice can be distributed much more widely.
So I totally agree with you that "everybody should learn to program" sounds very similar to "everybody can write a novel". It's wrong. But "everybody should be computer literate" is a very worthwhile cause.
What's included in basic computer literacy? Things that help people make better decisions every day of their lives. I know people that waste money, or put themselves into very difficult situations, through not understanding some of the following:
* An understanding of what happens when you turn a computer on or off. What's the difference between Office and Windows, and between OSX and Windows? Between iOS and an iPhone? I know people that have upgraded their 1-year-old computer, because they wanted the latest version of Windows.
* Basic security. Why is leaving a list of plain text passwords on your desktop (or even worse, on a Facebook note) a bad idea? Why should you avoid installing that funny game that comes with a cute emoticon toolbar?
* Difference between a markup language, a programming language, and a database. How do these systems communicate with each other? You've probably heard of people hiring a £1,000 per day IT consultant to make something bold on their homepage. Similar point about email, internet, web, and browsers. You could probably throw in the difference between being able to install Wordpress, and code a CMS from scratch here too, so that people don't pay £2K for a vanilla install.
It's fine to say "ask somebody who does know" but when you're totally clueless, it's difficult to know what questions to ask which person.
What I'm unsure about though is which specific skills and knowledge are most important. For instance, a huge number of people would benefit from more advanced skills with something like Excel, both in their home life and even more in any kind of job where you use a computer. But then there's a set of people who would benefit more from knowing how to do some other thing on the computer.
Everyone's subset of knowledge of English reading/writing is only slightly different. But with computers two people can know a lot about computers but know hardly anything in common. So what should be taught?
I've long thought that the most important thing is to be curious and willing to try things on the computer, because you'll end up figuring out whatever you want. But maybe there are people for whom computer skills would be very useful but they'll only learn them if it's taught. I know there are a lot of things I learned in college that I wouldn't have discovered on my own because I never would have known to read about them.
There are certain concepts that all advanced users of computers know, but about which there is a damaging lack of understanding amongst beginners.
As an example, a basic understanding of HTTP (not necessarily calling it that) would save people lots of money on their phone bill. I know plenty of people who see "1GB download limit" on their mobile contract and think that's fine "because they never download on their phone". When you explain that downloading includes refreshing their Facebook app, checking football scores, etc, they don't understand. Nor do they understand why they always go over the download limit.
So knowing what it means when you say 'download' is a universal benefit. If you're using a computer of some description in the 21st century, downloading something will be unavoidable.
Conversely, you can get by on a computer without ever using Excel or any kind of spreadsheet application. So while it would be tremendously useful to a very large number of people, it's not a fundamental in the same way as knowing the difference between a file and an application.
This is perhaps the most insightful comment I've encountered about computer literacy (and, maybe, literacy in general). Thank you for posting it and enlightening me a bit.
OP is specifically addressing the fact that employers are trying to increase the supply of actual programmers by encouraging more people to learn to program, not just learn the difference between on or off states.
It’s a non-altruistic push to increase the supply of something that is in high demand.
From the original, original article:
> What we nonexperts do possess is the ability to know enough about how these information systems work that we can be useful discussing them with others.
He's not arguing that we should all become programmers to increase the number of programmers. Instead, he's saying that you cannot be effective in any role in the agency if you're not computer literate. I'm inclined to agree.
I was able to this because I recognized:
1. X is a valuable problem 2. X can be automated
Other businesspeople recognized (1) and other programmers recognized (2), but nobody had put them together because the businesspeople lacked computer literacy and the programmers lacked business literacy.
So I agree that even basic computer literacy skills can be enormously valuable. It's a bit of a multiplicative effect: if all you have is basic computer literacy, that's not enough. But simple computer skills + strong business skills or simple business skills + strong computer skills are both very powerful combinations.
Knowing what people want + programming is valuable because it falls into the framework of (doing the right things) + (executing well.) Then something like teaching skills + programming leads to the Khan Academy, which was something that essentially wasn't possible before.
On the other hand, I would assume that programming + juggling doesn't have much synergy-it seems like most things you could do with programming + juggling could be done either with juggling skills or programming skills. Somebody will probably prove me wrong, though ;)
Programming includes computer literacy but goes far beyond basic comfort with computers and ability to use end-user tools. Mr McDonald may have been talking about computer literacy and I just missed it, but he didn't use that common term anywhere. Instead he referred to coding, programming, APIs, Python. He wrote "...you'd be well-advised to learn how to speak computer code" and "...learning basic computer language," two turns of phrase I wouldn't expect to hear from a programmer. He encourages "dabbling" with Python. He concludes with "Once you can claim familiarity with at least two programming languages, start sending out those resumes." That isn't espousing computer literacy, it's espousing learning to program.
I don't disagree with Mr. McDonald's sentiments about the mismatch between jobs and college graduates, though I would look beyond the Comp Sci graduating class if I was hiring. I disagree with the idea that everyone can or should learn to program -- learn and use a computer language. That's an idea that has gained traction lately and Mr. McDonald is just repeating it in puff piece for his own company (my opinion).
a) modeling business specs into discrete technical steps (loops, workflows, calls, etc.); b) developing intuition for tackling bugs, e.g. knowing where to look for causes and how to fix them quickly, even if it often sounds like a completely illogical thing to do; c) developing and sticking to well-defined procedures, e.g. documenting code, making timely backups, going through security checklists and so on.
So whenever I need to hire a new developer for my projects, I try to assess how well he fits those three criteria.
You've definitely homed in on three very important parts of being a good programmer as I define it. You're probably assuming some basic things like good communications (a won't happen without that) and using source code control when the project is big enough (I assume a part of c, but indeed backups come first and in small companies I tended to take that over) ... and I'm struggling to think of something you haven't covered that's relevant to your domain.
And, yeah, it sounds completely illogical, but after a while if you're good you do develop "intuition" that guides you in quickly finding bugs.
I'm curious what you ask in interviews.
The easiest thing to do is to ask new candidates to walk me through how they would model a specific business problem we've worked on before. Since I like to listen in on developer talk, I am usually aware of technical challenges that different approaches entail and listen to whether the candidate spots them or offers a way to deal with them when prompted.
I am also very curious to see how the candidate approaches the problem itself. In my experience, average developers feel they are done with the task when they explain how the program will work, while great developers are done when they explain how the program will work even when something it depends on doesn't work (e.g. how to you handle errors and outliers).
Obviously, I ask my developer colleagues to evaluate candidate's sample code.
Talking about testing is pretty fun too, just asking candidates what were the most nerve-wrecking debugging stories they had, reveals how much experience they have in this area. Then I would drill the candidate about testing routines and heuristics he employs; rule of the thumb is that the more specific candidate is, the more he knows about testing. Listening to heuristics also gives you an impression of how creative/crazy people are.
Finally, walking through a specific project the candidate has worked on in the (recent) past helps to understand what workflows & routines he follows in his daily routines. Here though you have to remember to ask clarifying questions along the way.
I am a self taught programmer and began learning about 6 years ago. I have spent probably a 1000 late nights hacking and learning in addition to working fulltime as a developer. Most of the other developers/programmers/engineers that I know have done the same. It takes MANY hours of debugging projects/issues and problems to gain a core understanding of the art of software development IN ADDITION to ones chosen language and associated toolchain.
Anyone who thinks they can learn this and be hirable/good without INVESTING serious time and energy is kidding themselves.
'Professional Programming' is a craft that takes time to cultivate and master.
McDonald, in the WSJ, said that if you don't at least try to understand some of the tech behind the scenes, you are basically a tool and won't get hired by him and other modern CEOs for any of his business roles. He didn't say that you have to BECOME a programmer, or even try; he just said to walk a mile in developer shoes to recognize some of what it's like.
TypicalProg says that there is more to programming than just hacking on python for a weekend...
Both are true, and both are different points.
So many comments on HN about "clueless bosses", yet here's a guy who says, in the WSJ for all to hear, that he wants to eliminate that. He doesn't say he wants to replace real devs with weekend-warriors. He says that if you want to work in the real world, you need to understand some of the tech behind the scenes.
How is this different from bankers learning finance, or doctors learning about medicine? B/c, as it turns out, EVERY job touches tech, and his point is that if you don't suck it up and learn some tech, no matter what job you do, you won't do as well as you could in it. He's not expecting everyone to code, he's expecting everyone to have some appreciation of _what it takes to code_.
I'm kind of astonished at the defensive comments, actually. I too require that anyone working for me learn about the tech behind the magic. Why? Because it creates RESPECT for the developers. Every negative comment about clueless bosses reflects a time when a developer has been subject to a lack of _respect_ and _appreciation_ for what it takes to make production-level digital experiences.
McDonald appear to recognizes that flaw, and is trying to fix it. He admits he's not a dev, and so he tries to understand enough to do no evil. Isn't that the level of respect we would want from any boss, esp a CEO outside of the "tech" or "engineering" group in a company?
I don't know him, but I agree with him. I'm surprised to see some of the vitriol. We should be encouraging more folks to try programming to learn that it's harder than it looks in some cases, easier in others, and overall, deserves some more respect as both a technical but also creative art. And that it's rapidly becoming a necessary knowledge for working in the modern age.
But as TP said, a bit of programming teaches you nothing useful about managing tech.
If I'm going to deal with builders in my job, it doesn't help anyone that I spend a weekend building a bird feeder. They talk structural integrity and insulation levels to me, and my experience based managing "How do you assure the planks are aligned correctly? I have some extra nails in my shed - can I reduce costs by donating them to the project?" does nothing but annoy and insult.
As a techie, my job is to make technical decisions, and translate technical considerations to the business people. I do not expect them to understand my field; I expect them to respect my expertise.
So in terms of your analogy, if building the bird feeder was necessary for you to understand the difference between a nail and a plank so that you could at least have a conversation with the builders, then it was a very good idea.
You would be surprised how strong you can make a plywood structure using this method.
To get curves you might need to steam the plywood into place though.
I understand that I don't have full expertise and I always listen to our devs, however it really helps me when I understand what they are talking about and I listen to them.
Also since I can quickly make some stuff from code I can google on the web, I'm much more productive than the average Joe when I got some repetitive task: make some excel function to deal with ugly data parsing, automate some data entry with auto-it or python+selenium, make some basic sql queries when I need a quick report...
On the other hand half of the people I work with can't write a simple vlookup formula or getting confused when it doesn't match a text to number, despite having excel in their CV.
When a person knows how computer magic works is only a benefit in my opinion and would be a strong bonus point for a job candidate.
Do you have any evidence to support that statement? I don't think respect comes from knowing couple of things behind the magic and even related to that knowledge in any way. I tend to think that people who have mastered something respect others' expertise a lot more, than people who haven't.
To me, Kirk McDonald comes off as clueless and arrogant as Dilbert's boss. Calling himself "your next potential dream boss", using weird phrases that no one uses like "speaking computer code," and believing that taking a summer programming class means you can provide development effort estimates to clients!
The two are only rudimentary related, and the notion that doing some basic coding is enough to understand, let alone get some appreciation of what it takes to code is insulting. That's not "walking a mile in developer shoes", it's just picking them up and see what size they are...
It will have the exact opposite result of creating respect for the developers. It equates developers to simple codemonkeys.
There many things you can do to get a better understanding of software development, and it's wonderful if non-programmers that have to work with or manage engineers would make the effort to do just that.
But Mr. McDonald's ideas about programming and what to do to get a better understanding of it are based on patronizing and insulting prejudices. There's no respect there.
Also, respect doesn't require fucking about with code. I can respect the craftsmanship of a plumber and the skill and knowledge of a surgeon without having to fix a boiler or cut open a human being, thank you very much.
Come to think of it, McDonald is actually insulting the abilities of people on both sides of the equation. The only person who mr. McDonald seems to be genuinely impressed with is mr. McDonald.
Forget about the "probably". Most people on HN would want to avoid an employer like that like the plague.
Most employers can be taught about how to get the best out of their developers, and most of the time all it takes is programmers to open their mouths instead of bitching on HN or proggit.
But with an ego like mr. McDonald, who shows so little understanding about what it means to be a programmer but is totally convinced he knows it all, I wouldn't bother trying.
- simple automation and tool usage
How many billions of hours of productivity are lost because people are manually retyping or reformatting data that could be quickly and easily scripted (with only basic knowledge) or done using commands/tools already present on the system? Quite a lot. How much more effective could people be if they could run even simple queries against the data in their domain? These things aren't difficult, people just don't know that they can do them.
- making things more efficient
Related to the above, a basic understanding of how to handle data in a way that can be processed, and how to make things organized and open to processing, could go a long way. It doesn't take much programming to realize that text files are much easier to process than Word documents, or that a consistently-formatted spreadsheet is reusable while one with the data scattered around for visual effect is not.
- learning to distinguish between things that are easy or difficult to do with programming
Lots of good ideas get nixed because someone doesn't want to spend a lot of time and money, or bother the developers, when in reality it's something that could be done in about the time it took to describe it (or less). And we all have plenty of examples of people assuming that something difficult should be quick, easy, and cheap. While it takes a lifetime of experience to be good at estimating such things, and it varies greatly depending on domain and tools used, a little bit of knowledge of how computers work could go a long way in some cases.
And for those who say that programming is not for everyone, think of basic math and accounting. Everyone may not be a professional accountant, but everyone has to deal with money. Would you want someone in charge who doesn't even understand that costs need to be lower than revenues to generate a profit? Or that doesn't know how to calculate 5% of $10,000? Some basic knowledge is useful regardless of what you do.
Every single one of those teams would have benefited from having someone who can do at least basic scripting for automating repetitive tasks.
The thing is, if you want to build a custom file rename-er in python, you cannot google the answer. You don't need the skills and abilities of a professional developer, but you need far more than an afternoon.
So yeah, that's just one example of why many, many, more people should learn to code. The computers are tools and there's no reason why 99.99% of the users should be only pointing and clicking while a chosen few are the sorcerers behind the scenes.
However, starting from logic gates, and getting to spreadsheet usage or the basics of HTTP is almost as far, and would require starting very early. It wouldn't be bad to do that, but would be a big change, and would probably have to take time from something else.
I will say that the ability to find patterns is crucial to learning natural languages as much as programming. As is the important of finding context. Likewise being "technical" as in being comfortable with technology and a willingness and patience to learn it are important as well. But I would take a car to the garage instead of trying to fix it myself (knowing about how the car works a little bit helps me avoid getting ripped of).
I'd like to point out that this quote was originally directed at Jack Kerouac. This possibly helped establish the myth that On The Road was actually produced in three weeks[1].
[1]http://en.wikipedia.org/wiki/On_the_Road#Production_and_publ...
I expected an article ridiculing the expectations of agency execs with nonsense comms projects, i.e.: that addresses the spuriousness of the commissions, not the incompetence of their management.
There's nothing wrong with encouraging people to give it a go, and there's nothing wrong with learning the basics of coding regardless of what role you're in.
Just be prepared to let the pros do their jobs and don't assume your small amount of knowledge is equal (or superior).
>I never learned to skateboard. I can’t dance. I can’t play a musical instrument. I struggle learning foreign languages. I know people who can do those things well.
The reason people need to become programmers is because, while people love to skateboard and dance, that shit don't pay.
Programming gets money. It's the only white collar job that doesn't artificially limit the number of people entering the field--in fact programmers seem to actively support importing foreign workers to compete with them for jobs. That's a new development in history. A group of professionals eager to give a helping hand to low-wage competition.
Expect more dilution of the talent pool.
There's infinite demand for problem solving: making existing processes better. The limiting factor there is trust. How do you make people trust your judgement enough that they'll take your suggestions seriously?
Where there is finite (and plummeting) demand is over subordinate labor: pre-defined work that someone has already decided to pay a fixed amount for. All of that stuff is getting off-loaded to machines or off-shored to low-wage countries.
Labor finitism is the idea that there's a finite amount of paid subordinate work to go around and that we're doomed to compete for a waning quantity of it. Labor progressivism is the idea that, when one block of grunt work is automated, it frees up energy to move to something more interesting (and less subordinate, but more profitable).
Fifty years ago, it didn't matter whether labor finitism or progressivism was a better model of the "true" underlying behavior of society, because we were at full employment and technology didn't change as fast as it does now.
Now, it's a genuine and unresolved question: are we doing the right thing when we, in earnest, do the best job we can at making existing processes more effective? Are we building the skills and credibility that will help us graduate to better work, or are we programming ourselves out of jobs and shutting down the middle class? Right now, it's not clear which. I'd say that labor progressivism is winning, but just barely. For labor progressivism to be true, people need credibility and trust and risk allowance (savings) and those were traditionally won by taking subordinate jobs for ~10 years, but those are disappearing because labor finitism is correct over subordinate labor. The result of this is that the terms of subordinate labor are going to hell, and the people most likely to win in the new economy are those who can find a way to leapfrog that increasingly unprofitable slog.
This is arguably the single biggest issue I've faced in over 20 years as first a programmer and since 2001, an architect.
The result? Trust is easy to get. I'd argue that credibility precedes it, and that's also easy to establish. The caveat is that it requires social skills, and must be done at the outset.
Building relationships that establish trust and credibility requires not focusing on building relationships.
When a new project starts I focus on three things - understanding the current situation, establishing a business objective, and bounding the scope. I do that by getting off my arse, meeting people, finding out what they need to succeed, and listening.
And by not talking, but mostly prompting or re-stating someone's problem in my own words, I build the trust I need from them.
[Edit] It's a bit badly articulated because I'm still formulating the idea, but over the last few months I've tried to put my thoughts down - http://www.wittenburg.co.uk/Entry.aspx?id=8ec91ced-b3a4-4b07...
While management at most companies is dysfunctional, this problem is 90% our fault.
Try asking a hacker how many dollars they contributed to the bottom line at their last job, and they'll give you a blank stare.
Try asking 10 hackers what their top 1-3 most valuable contributions were at their previous company. Most of them will immediately dive into the details of what they did rather than how it affected the business.
Ask them to quantify those achievements in terms of dollars, or user growth, or any metrics that the business cares about, and maybe 2 will be able to answer.
I'm not talking about asking for immediate answers either. Most hackers can take days and still have a hard time quantifying their contributions.
This gives the impression that the most programmers-even great ones-either are completely unaware of how they affect the business, or don't care.
And if you don't know how something impacts the business, no one will trust your ability to prioritize.
We as a community need to learn to speak the language of dollars, growth, and business objectives if we want to be taken seriously. Otherwise we're just tossing out ideas without articulating how valuable they are.