Skip navigation
Help

T.Y.S.O.N.

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

I hesitate to say everyone should have a child, because becoming a parent is an intensely personal choice. I try my best to avoid evangelizing the experience, but the deeper in I get, the more I believe that nothing captures the continued absurdity of the human condition better than having a child does.

After becoming a parent, the first thing you'll say to yourself is, my God, it is a miracle any of us even exist, because I want to freakin' kill this kid at least three times a day. But then your child will spontaneously hug you, or tell you some stupid joke that they can't stop laughing at, or grab for your hand while crossing the street and then … well, here we all are, aren't we? I'm left wondering if I'll ever be able to love other people – or for that matter myself – as much as I love my children. Unconditional, irrational, nonsensical love. That's humanity in a nutshell.

Parenting is by far the toughest job I've ever had. It makes my so-called career seem awfully quaint in comparison.

the first 9 months is the hardest

My favorite part of the parenting process, though, is finally being able to talk to my kids. When the dam breaks and all that crazy stuff they had locked away in those tiny brains for the first two years comes uncontrollably pouring out. Finding out what they're thinking about and what kind of people they are at last. Watching them discover and explore the surface of language is utterly fascinating. After spending two years trying to guess – with extremely limited success – what they want and need, truly, what greater privilege is there than to simply ask them? Language: Best. Invention. Ever. I like it so much I'm using it right now!

Language also allows kids to demonstrate just what crazy little roiling balls of id they (and by extension, we) all are on the inside. Kids don't know what it means to be mad, to be happy, to be sad. They have to be taught what emotions are, how to handle them, and how to deal in a constructive way with everything the world is throwing at them. You'll get a ringside seat to this process not as a passive observer, but as their coach and spirit guide. They have no coping mechanisms except the ones we teach them. The difference between a child who freaks out at the slightest breeze, and a child who can confidently navigate an unfamiliar world? The parents.

See, I told you this was going to be tough.

There are of course innumerable books on parenting and child-rearing, most of which I have no time to read because by the time I'm done being a parent for the day, I'm too exhausted to read more about it. And, really, who wants to read about parenting when you're living the stuff 24/7? Except on Parenting Stack Exchange, of course. However, there is one particular book I happened to discover that was shockingly helpful, even after barely ten pages in. If you ever need to deal with children aged 2 to 99, stop reading right now and go buy How to Talk So Kids Will Listen & Listen So Kids Will Talk.

How to Talk So Kids Will Listen & Listen So Kids Will Talk

We already own three copies. And you're welcome.

What's so great about this book? I originally found it through A.J. Jacobs, who I mentioned in Trust Me, I'm Lying. Here's how he describes it:

The best marriage advice book I’ve read is a paperback called How to Talk So Kids Will Listen & Listen So Kids Will Talk. As you might deduce from the title, it wasn’t meant as a marriage advice book. But the techniques in this book are so brilliant, I use them in every human interaction I can, no matter the age of the conversant. It’s a strategy that was working well until today.

The book was written by a pair of former New York City teachers, and their thesis is that we talk to kids all wrong. You can’t argue with kids, and you shouldn’t dismiss their complaints. The magic formula includes: listen, repeat what they say, label their emotions. The kids will figure out the solution themselves.

I started using it on Jasper, who would throw a tantrum about his brothers monopolizing the pieces to Mouse Trap. I listened, repeated what he said, and watched the screaming and tears magically subside. It worked so well, I decided, why limit it to kids? My first time trying it on a grown-up was one morning at the deli. I was standing behind a guy who was trying unsuccessfully to make a call on his cell.

“Oh come on! I can’t get a signal here? Dammit. This is New York.”
He looked at me.
“No signal?” I say. “Here in New York?” (Repeat what they say.)
“It’s not like we’re in goddamn Wisconsin.”
“Mmmm.” (Listen. Make soothing noises.)
“We’re not on a farm. It’s New York, for God’s sake,” he said.
“That’s frustrating,” I say. (Label their emotions.)
He calmed down.

This book taught me that, as with so many other things in life, I've been doing it all wrong. I thought it was my job as a parent to solve problems for my children, to throw myself on life's figurative grenades to protect them. Consider the following illustrated examples from the book.

How to Talk So Kids Will Listen, cartoon about empathy

Notice how she cleverly lets the child reach an alternative solution himself, rather than providing the "solution" to him on a silver platter as the all-seeing, all-knowing omniscient adult. This honestly would never have occurred to me, because, well, if we're out of Toastie Crunchies, then we are out of freaking Toastie Crunchies!

How to Talk So Kids Will Listen, cartoon about description

I've learned to fall back whenever possible to simply describing things or situations instead of judging or pontificating. I explain the consequences of potential actions rather than jumping impatiently to "don't do that".

How to Talk So Kids Will Listen & Listen So Kids Will Talk is full of beautiful little insights on human interaction like this, and I was surprised to find how often what I thought was a good parenting behavior was working against us. Turns out, children aren't the only ones who have trouble dealing with their emotions and learning to communicate. I haven't just improved my relationship with my kids using the practical advice in this book, I've improved my interactions with all human beings from age 2 to 99.

Kids will teach you, if you let them. They'll teach you that getting born is the easy part. Anyone can do that in a day. But becoming a well-adjusted human being? That'll take the rest of your life.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

0
Your rating: None

I didn't intend for Please Don't Learn to Code to be so controversial, but it seemed to strike a nerve. Apparently a significant percentage of readers stopped reading at the title.

So I will open with my own story. I think you'll find it instructive.

My mom once told me that the only reason she dated my father is because her mother told her to stay away from that boy, he's a bad influence.

If she had, I would not exist.

True story, folks.

I'd argue that the people who need to learn to code will be spurred on most of all by honesty, not religious faith in the truthiness of code as a universal good. Go in knowing both sides of the story, because there are no silver bullets in code. If, after hearing both the pros and cons, you still want to learn to code, then by all means learn to code. If you're so easily dissuaded by hearing a few downsides to coding, there are plenty of other things you could spend your time learning that are more unambiguously useful and practical. Per Michael Lopp, you could learn to be a better communicator. Per Gina Trapani, you could learn how to propose better solutions. Slinging code is just a tiny part of the overall solution in my experience. Why optimize for that?

On the earliest computers, everyone had to be a programmer because there was no software. If you wanted the computer to do anything, you wrote code. Computers in the not so distant past booted directly to the friendly blinking cursor of a BASIC interpreter. I view the entire arc of software development as a field where we programmers spend our lives writing code so that our fellow human beings no longer need to write code (or even worse, become programmers) to get things done with computers. So this idea that "everyone must know how to code" is, to me, going backwards.

Grace-hopper-and-the-univac

I fully support a push for basic Internet literacy. But in order to be a competent driver, does everyone need to know, in detail, how their automobile works? Must we teach all human beings the basics of being an auto mechanic, and elevate shop class to the same level as English and Mathematics classes? Isn't knowing how to change a tire, and when to take your car in for an oil change, sufficient? If your toilet is clogged, you shouldn't need to take a two week in depth plumbing course on toiletcademy.com to understand how to fix that. Reading a single web page, just in time, should be more than adequate.

What is code, in the most abstract sense?

code (kōd) …

    1. A system of signals used to represent letters or numbers in transmitting messages.
    2. A system of symbols, letters, or words given certain arbitrary meanings, used for transmitting messages requiring secrecy or brevity.
  1. A system of symbols and rules used to represent instructions to a computer…

The American Heritage Dictionary of the English Language

Is it punchcards? Remote terminals? Emacs? Textmate? Eclipse? Visual Studio? C? Ruby? JavaScript? In the 1920s, it was considered important to learn how to use slide rules. In the 1960s, it was considered important to learn mechanical drawing. None of that matters today. I'm hesitant to recommend any particular approach to coding other than the fundamentals as outlined in Code: The Hidden Language of Computer Hardware and Software, because I'm not sure we'll even recognize coding in the next 20 or 30 years. To kids today, perhaps coding will eventually resemble Minecraft, or building levels in Portal 2.

But everyone should try writing a little code, because it somehow sharpens the mind, right? Maybe in the same abstract way that reading the entire Encyclopedia Brittanica from beginning to end does. Honestly, I'd prefer that people spend their time discovering what problems they love and find interesting, first, and researching the hell out of those problems. The toughest thing in life is not learning a bunch of potentially hypothetically useful stuff, but figuring out what the heck it is you want to do. If said research and exploration leads to coding, then by all means learn to code with my blessing … which is worth exactly what it sounds like, nothing.

So, no, I don't advocate learning to code for the sake of learning to code. What I advocate is shamelessly following your joy. For example, I received the following email yesterday.

I am a 45 year old attorney/C.P.A. attempting to abandon my solo law practice as soon as humanly possible and strike out in search of my next vocation. I am actually paying someone to help me do this and, as a first step in the "find yourself" process, I was told to look back over my long and winding career and identify those times in my professional life when I was doing something I truly enjoyed.

Coming of age as an accountant during the PC revolution (when I started my first "real" job at Arthur Andersen we were still billing clients to update depreciation schedules manually), I spend a lot of time learning how to make computers, printers, and software (VisiCalc anyone?) work. This quasi-technical aspect of my work reached its apex when I was hired as a healthcare financial analyst for a large hospital system. When I arrived for my first day of work in that job, I learned that my predecessor had bequeathed me only a one page static Excel spreadsheet that purported to "analyze" a multi-million dollar managed care contract for a seven hospital health system. I proceeded to build my own spreadsheet but quickly exceeded the database functional capacity of Excel and had to teach myself Access and thereafter proceeded to stretch the envelope of Access' spreadsheet capabilities to their utmost capacity – I had to retrieve hundreds of thousands of patient records and then perform pro forma calculations on them to see if the proposed contracts would result in more or less payment given identical utilization.

I will be the first to admit that I was not coding in any professional sense of the word. I did manage to make Access do things that MS technical support told me it could not do but I was still simply using very basic commands to bend an existing application to my will. The one thing I do remember was being happy. I typed infinitely nested commands into formula cells for twelve to fourteen hours a day and was still disappointed when I had to stop.

My experience in building that monster and making it run was, to date, my most satisfying professional accomplishment, despite going on to later become CFO of another healthcare facility, a feat that should have fulfilled all of my professional ambitions at that time. More than just the work, however, was the group of like-minded analysts and IT folks with whom I became associated as I tried, failed, tried, debugged, and continued building this behemoth of a database. I learned about Easter Eggs and coding lore and found myself hacking into areas of the hospital mainframe which were completely offlimits to someone of my paygrade. And yet, I kept pursuing my "professional goals" and ended up in jobs/careers I hated doing work I loathed.

Here's a person who a) found an interesting problem, b) attempted to create a solution to the problem, which naturally c) led them to learning to code. And they loved it. This is how it's supposed to work. I didn't become a programmer because someone told me learning to code was important, I became a programmer because I wanted to change the rules of the video games I was playing, and learning to code was the only way to do that. Along the way, I too fell in love.

All that to say that as I stand at the crossroads once more, I still hear the siren song of those halcyon days of quasi-coding during which I enjoyed my work. My question for you is whether you think it is even possible for someone of my vintage to learn to code to a level that I could be hired as a programmer. I am not trying to do this on the side while running the city of New York as a day job. Rather, I sincerely and completely want to become a bona fide programmer and spend my days creating (and/or debugging) something of value.

Unfortunately, calling yourself a "programmer" can be a career-limiting move, particularly for someone who was a CFO in a previous career. People who work with money tend to make a lot of money; see Wall Street.

But this isn't about money, is it? It's about love. So, if you want to be a programmer, all you need to do is follow your joy and fall in love with code. Any programmer worth their salt immediately recognizes a fellow true believer, a person as madly in love with code as they are, warts and all. Welcome to the tribe.

And if you're reading this and thinking, "screw this Jeff Atwood guy, who is he to tell me whether I should learn to code or not", all I can say is: good! That's the spirit!

[advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today!

0
Your rating: None

The whole "everyone should learn programming" meme has gotten so out of control that the mayor of New York City actually vowed to learn to code in 2012.

Bloomberg-vows-to-code

A noble gesture to garner the NYC tech community vote, for sure, but if the mayor of New York City actually needs to sling JavaScript code to do his job, something is deeply, horribly, terribly wrong with politics in the state of New York. Even if Mr. Bloomberg did "learn to code", with apologies to Adam Vandenberg, I expect we'd end up with this:

10 PRINT "I AM MAYOR"
20 GOTO 10

Fortunately, the odds of this technological flight of fancy happening – even in jest – are zero, and for good reason: the mayor of New York City will hopefully spend his time doing the job taxpayers paid him to do instead. According to the Office of the Mayor home page, that means working on absenteeism programs for schools, public transit improvements, the 2013 city budget, and … do I really need to go on?

To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can't see it.

Look, I love programming. I also believe programming is important … in the right context, for some people. But so are a lot of skills. I would no more urge everyone to learn programming than I would urge everyone to learn plumbing. That'd be ridiculous, right?

Advice-for-plumbers

The "everyone should learn to code" movement isn't just wrong because it falsely equates coding with essential life skills like reading, writing, and math. I wish. It is wrong in so many other ways.

  • It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can't get behind that. You should be learning to write as little code as possible. Ideally none.
  • It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it's not. Their job is to solve problems. Don't celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.
  • It puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?
  • It assumes that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the workforce is a net positive for the world. I guess that's true if you consider that one bad programmer can easily create two new jobs a year. And for that matter, most people who already call themselves programmers can't even code, so please pardon my skepticism of the sentiment that "everyone can learn to code".
  • It implies that there's a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.

I suppose I can support learning a tiny bit about programming just so you can recognize what code is, and when code might be an appropriate way to approach a problem you have. But I can also recognize plumbing problems when I see them without any particular training in the area. The general populace (and its political leadership) could probably benefit most of all from a basic understanding of how computers, and the Internet, work. Being able to get around on the Internet is becoming a basic life skill, and we should be worried about fixing that first and most of all, before we start jumping all the way into code.

Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Instead, I humbly suggest that we spend our time learning how to …

  • Research voraciously, and understand how the things around us work at a basic level.
  • Communicate effectively with other human beings.

These are skills that extend far beyond mere coding and will help you in every aspect of your life.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

0
Your rating: None

There's no magic bullet for hiring programmers. But I can share advice on a few techniques that I've seen work, that I've written about here and personally tried out over the years.

1. First, pass a few simple "Hello World" online tests.

I know it sounds crazy, but some people who call themselves programmers can barely program. To this day, I still get regular pings from people who tell me they had candidates fail the most basic programming test imaginable.

That's why extremely simple programming tests are step one of any sane interview process. These tests should happen online, and the goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it's sad and kind of depressing that this is even necessary, but if you don't perform this sanity check, trust me – you'll be sorry.

Some services that do online code screening (I am sure there are more, but these are the ones I know about) are Interview Zen and codility.

2. Ask to see their portfolio.

Any programmer worth their salt should have a portfolio of the things they've worked on. It doesn't have to be fancy. I'm just looking for a basic breadcrumb trail of your awesomeness that you've left on the Internet to help others. Show me a Stack Overflow profile where I can see what kind of communicator and problem solver you are. Link me to an open-source code repository of your stuff. Got a professional blog? A tumblr? A twitter? Some other word I've never heard of? Excellent, let's have a look. Share applications you've designed, or websites you worked on, and describe what parts were yours.

Just seeing what kind of work people have done, and what sort of online artifacts they've created, is tremendously helpful in getting a sense of what people do and what they're good (or bad) at.

3. Hire for cultural fit.

Like GitHub, I find that cultural fit is often a stronger predictor of success than mad programming chops.

We talk about [philosophy] during the hiring process, which we take very seriously. We want any potential GitHubber to know what they’re getting into and ensure it’s a good fit. Part of that is having dinner and talking about stuff like the culture, philosophy, mistakes we’ve made, plans, whatever.

Early on we made a few hires for their skills with little regard to how they’d fit into the culture of the company or if they understood the philosophy. Naturally, those hires didn’t work out. So while we care about the skills of a potential employees, whether or not they “get” us is a major part too.

I realize that not every business has a community around what they do, but if you do have a community you should try like hell to hire from your community whenever possible. These are the folks who were naturally drawn to what you do, that were pulled into the gravitational well of your company completely of their own accord. The odds of these candidates being a good cultural fit are abnormally high. That's what you want!

Did a few of your users build an amazing mod for your game? Did they find an obscure security vulnerability and try to tell you about it? Hire these people immediately!

4. Do a detailed, structured phone screen.

Once you've worked through the above, it's time to give the candidate a call. Bear in mind that the phone screen is not for chatting, it's for screening. The call should be technical and structured, so both of you can get out immediately if it clearly isn't a fit. Getting the Interview Phone Screen Right covers the basics, but in summary:

  1. A bit of on-the-fly coding. "Find the largest int value in an int array."
  2. Some basic design. "Design a representation to model HTML."
  3. Scripting and regular expressions. "Give me a list of the text files in this directory that contain phone numbers in a specific format."
  4. Data structures. "When would you use a hashtable versus an array?"
  5. Bits and bytes. "Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny?"

What you're looking for is not magical perfect answers, necessarily, but some context into how this person solves problems, and whether they know their stuff (plus or minus 10 percent). The goal is to make sure that the candidates that do make it to the next step are not wasting their time or yours. So don't be shy about sticking to your guns and ending the call early if there are too many warning flags.

5. Give them an audition project.

So the candidate breezed through the hello world programming tests, has an amazing portfolio, is an excellent cultural fit, and also passed the phone screen with flying colors. Time to get them in for a face-to-face interview, right? Not so fast there cowboy!

I've seen candidates nail all of the above, join the company, and utterly fail to Get Things Done. Have I mentioned that hiring programmers is hard?

If you want to determine beyond the shadow of a doubt if someone's going to be a great hire, give them an audition project. I'm not talking about a generic, abstract programming problem, I'm talking about a real world, honest-to-God unit of work that you need done right now today on your actual product. Something you would give to a current employee, if they weren't all busy, y'know, doing other stuff.

This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement. Select a small project that can ideally be done in a few days, maybe at most a week or two. Either the candidate can come in to the office, or they can work remotely. I know not every business has these bite-sized units of work that they can slice off for someone outside the company – but trying desperately to make it inside the company – to take on. I'd argue that if you can't think of any way to make an audition mini-project work for a strong hiring candidate, perhaps you're not structuring the work properly for your existing employees, either.

If the audition project is a success, fantastic – you now have a highly qualified candidate that can provably Get Things Done, and you've accomplished something that needed doing. To date, I have never seen a candidate who passes the audition project fail to work out. I weigh performance on the audition project heavily; it's as close as you can get to actually working the job without being hired. And if the audition project doesn't work out, well, consider the cost of this little consulting gig a cheap exit fee compared to an extensive interview process with 4 or 5 other people at your company. Worst case, you can pass off the audition project to the next strong candidate.

(A probationary period of conditional employment can also work, and is conceptually quite similar. You could hire with a 6-8 week review "go or no go" decision everyone agrees to in advance.)

6. Get in a room with us and pitch.

Finally, you should meet candidates face-to-face at some point. It's inevitable, but the point of the earlier steps is that you should be 95% certain that a candidate would be a great hire before they ever set foot in an interview room.

I'm far from an expert on in person interviews, but I don't like interview puzzle questions, to put it mildly.

Instead, I have my own theory about how we should interview programmers: have the candidate give a 15 minute presentation on their area of expertise. I think this is a far better indicator of success than a traditional interview, because you'll quickly ascertain …

  • Is this person passionate about what they are doing?
  • Can they communicate effectively to a small group?
  • Do they have a good handle on their area of expertise?
  • Would your team enjoy working with this person?

The one thing every programmer should know, per Steve Yegge, is how to market yourself, your code, and your project. I wholeheartedly agree. Now pitch me!

7. None of this is guaranteed.

Please take this list at face value. I've seen these techniques work, and I've occasionally seen them not work. Adapt this advice to your your particular situation, keep what you think makes sense, and ignore the rest (although I'd strongly advise you to never, ever skip step #1). Even in the best of circumstances, hiring human beings is hard. A job opportunity may not work out for reasons far beyond anyone's control. People are, as they say, complicated.

If you think of work as a relationship, one you'll spend 40 hours a week (or more) in the rest of your life, it behooves everyone involved to "date smart". Both the company and the candidate should make a good faith best effort to determine if there's a match. Your goal shouldn't be merely to get a job, or hire someone for a job, but to have fun and create a love connection. Don't rush into anything unless it feels right on both sides.

(as an aside, if you're looking for ways to attract programmers, you can't go wrong with this excellent advice from Samuel Mullen.)

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

0
Your rating: None