Say, for instance, you are given a seemingly impossible task, that over the next thirty days you are to be twice as good as you are today. How might you accomplish that? Would you break it apart? Try to focus on the most meaningful changes first? Tackle them one at a time, perhaps utilizing some sort of list? Congratulations, you might be an engineer. Would you instead, shift uncomfortably in your chair, attempt to point fingers at others, pretend you’re doing fine, and quietly start looking for a new job? Congratulations, you’re an asshole.
First, let me say, that the goal of attaining the unicorn status of the 10x programmer is probably unattainable, but 2x is definitely within your grasp.
Improve your basic skills
The 2x speedup is not, I repeat, NOT from a new language or toolkit, it’s from mastering the basics. Using Angular instead of static html pages does not make you a better programmer. It’s possible, that once mastered, you can be more proficient in setting up rich, responsive and scalable single page web applications, than you would using a simpler toolchain, however this is not going to help you attain 2x in the next thirty days, so don’t waste your time. I don’t mean to pick on Angular, it could easily be React+Redux or any other such framework-du-jour. The point is that there are better uses of your time.
If you were a chef you would practice knife skills
If you were a ninja, you would practice nunchuck skills.
If you were a hairdresser you would practice cutting doll hair.
Why would software be any different?
Master basic keyboarding Skills
- Do you hunt and peck?
- Can you navigate your OS / Editor without your mouse?
- Can you type quickly and accurately for sustained periods of time?
- Did you know that holding control while moving left and right can advance a whole WORD at a time. Magic!
- Have you learned the joys of Ctrl+A and Ctrl+E instead of home/end?
- Seriously, rebind that shit. Your life will change for the better.
- You don’t have to go full emacs or vi binds, given the learning curve, but that could be a worthwhile long-term goal.
Set aside time to practice programming
Do it on the company dime or not that’s up to you. The point is to seek measurable improvement.
- Write a function.
- Now delete it.
- Write it again.
- Delete it.
- Continue until the function is perfect or your boss notices what you’re doing.
Get better tools
If you’re not willing to invest in yourself, then why would anyone else?
Do not decry your company for failing to provide you with adequate tools. Go out, find the tools, and if your company won’t buy them or approve them quickly buy them yourself or LEAVE.
Practice Taco Bell Programming
functionality is an asset, but code is a liability.
There is of course, value in re-inventing the wheel, but only to learn more about wheels. In the next 30 days, you have no such luxury. Work smarter, not harder.
Pick the simplest solution that could possibly work, test the hell out of it, and move on. My colleagues don’t have the luxury of the beautiful Linux tools that the author talks about here, but we should at least learn the lessons the Unix way. Make small composable units and combine them to make even more useful units. Repeat until you are the master of the universe.
Okay hopefully the non-nerds didn’t make it this far, and they don’t think to read up. I want them to take this seriously too, but honestly, nerds, realize your value. You are more vital to the company than they are. Now that you know that, stop being cowed into doing things by people just because they talk loudly at you or as “are you sure?”. These are laughably transparent attempts at manipulation, and they shouldn’t work on you. Man (or woman) up and do something about it.
My scrum master said that we’re behind schedule
My scrum master said she was going for coffee, anyone want one?
PS: It wouldn’t kill you to write a few tests too. Code fearlessly because you’re backed by tests
Don’t think I forgot about you. This concerns you too. If you would like to help these nerds achieve their dreams of literally doubling their output, and attain all the moneys that you so desperately want, then could you please do the following?
Understand the power dynamics, and stop abusing them
My favorite programming joke of all time goes like this:
How can you tell if you’re dealing with an extroverted programmer?
(pause for dramatic effect)
He’s staring at YOUR shoes!
(hold for applause)
Why does this joke work? Because it’s true. I touched on it perhaps a little too softly last time, so I’ll spell it out in no uncertain terms. Programmers are, generally speaking, afraid of confrontation and really bad at communication. If you take advantage of this fact, not only are you a terrible person, but you’re also doing yourself a disservice because again, you have no idea how this shit works.
If a meek expert tells you it’s going to take several days because of the [a bunch of shit you don’t understand], and you say: “Have it in by tomorrow”, they will likely not argue. You have just torpedoed your own project. Stop it.
Stop Breaking My Flow
This post was conceived and authored in a single day. Granted, it has been brewing for the last 10 years or so, but today was the day that it became manifest because I had a long swath of uninterrupted time to compose my thoughts.
If you stop interrupting people, they will produce double the output in half the time. They’re on a different schedule than you are, and you should respect that, or at the very least understand it. Maker Schedule vs Manager Schedule
Armchair Psychology 101
Freakanomics reminds us that people respond to incentives, but rarely in the way you expect. You cannot just pay people more money and expect better outcomes. In fact, you actually get worse outcomes.
Axiom: People are willing to work harder on something they care about, the quality is better, and they tend to stay at companies where this is true longer.
Sadly, you cannot force people to care, but you can trick them into it. Much like smiling to fool your brain into thinking you’re happy, you too can manipulate others to achieve your financial goals. Bonus: it’s good for them too.
- When they make something you like, praise them.
- When they make something you don’t like, tell them how they can make it better.
If you consistently pretend that the work they do matters, they might just start believing it.
One of my most rewarding work memories happened on a conference call to some vendors I had never met. The business owner I had been developing for said the phrase “They’ve built us a wonderful tool”. It took a handful of seconds and zero effort on his part, and it motivated me for months. If you can’t do this, you’re a bad leader, or a sadist, or both. Shout out to Matt Watters, wherever you are.
Mythical Man Month
If you are a project manager, scrum master, product owner, program manager, middle manager, release manager, delivery manager, and you have not read this book, you are wrong.
This is required reading for anyone in the software field, but doubly so if you are in charge of any aspect of delivery.
How does a large software project get to be one year late? One day at a time!
TLDR here are the cliff notes:
- Software projects fail a lot.
- More people slow down a project.
- Estimates are hard.
- Fixing bugs often results in more bugs.
I think that’s everything. As always, please don’t fire me.
Dear Sir or Madame in the suit,
Hi there! I’m a programmer, and I’m really good at what I do. I’m pretty sure you’re good at what you do too, but I think it’s safe to say that we’re good at different things. The thing is, people like me are usually working for people like you, and that’s cool, we like that arrangement for the most part. In general, we would much rather make shiny fun things than agonize over boring things like quarterly profit margins (ew). Unfortunately, because of this arrangement, we don’t always tell you the hard truth, because it’s way too easy to just fire us and find someone who is willing to lie to you. It’s just business.
I guess what I’m trying to say is that you’re kinda making this software thing harder than it needs to be.
Here are some things that we wish we could tell you:
We talk about you behind your back.
It’s true, and it’s not helping. We can whine to each other about what ails software development all day long, but until we engage people like you in the conversation, we’re just talking to ourselves. So I’m reaching out to you. Help us out here. In exchange, we’ll help you print all the money you need for your Scrooge McDuck-style gold doubloon swimming pool or whatever it is you want out of life.
Those fussy nerds in the room wearing plaid button-up shirts and blue jeans, looking meekly at their little notepads in order to avoid eye-contact control your profit and loss. They deserve to be treated with a little bit more respect than just some code monkey who makes the button blue. We get frustrated, but we still don’t say anything, we just silently walk away with years of knowledge that you can’t replace.
You should practice empathy, for selfish reasons.
Whichever model fits your specific world view, the fact is that these nerds are shy and you pay them a lot. If you push them around and intimidate them you cannot expect a solid return on that investment. Bear in mind, when I said “shy” earlier, I meant “cripplingly stunted socially”. You might think to yourself that this is the perfect situation for you, an extroverted captain of industry with all the best ideas. These nerds will do anything you ask them to, won’t speak up for themselves, and they aren’t out for your job? Sign me up!
The thing is… sometimes, and I mean this with all due respect: Your ideas are awful. I mean really awful. Like, “Let’s add a friendly paperclip that gives advice on your writing” awful. The kind of thing where any self-respecting technologist should stand up and walk out of the room because of how silly it is, but they have kids to feed, so… the system shall have a “clippy”.
“How long is this going to take?” is not the right question.
It’s totally a fair question, you should be allowed to ask it, but it ignores a lot of things; things you should care about. The “this” is so ill-defined that it’s nearly impossible to say for sure.
The astute reader will notice in this highly informative chart that I found on the internet, that there is no intersection of all three attributes.
This is the “Iron Triangle”, and it’s not really up for debate.
What you should be asking is, “What am I getting, and is that worth what I’m paying for it?”
Then, it’s easy to keep the “good” part as the constant, and flex only on what you deliver. Nobody wants bad code. Your customers will hate it, and all those precious dollars will not be yours. We can do better, but it starts with you.
Process won’t fix your problems.
If the above sounded like that “Agile” thing that your friend the product owner has told you so much about, you’re right, it does. Sadly, it’s not the whole answer. You can’t just manage your way out of this one. Process is a way of wrangling lots of people if varying levels of skill and motivation toward a common goal. This effect is not an enhancement, it is an average. It allows you to coalesce 10 developers, one of whom does 90% of the work, into a “team”, with a “velocity”, so that you can see some burn-down charts and feel good that work is being done. Here again, you are not being told the whole truth. There is overhead associated with gathering and maintaining these team metrics (most of which are fabricated anyway). The top performers burn out, the low performers can’t keep up, the project still fails.
The real solution is to have just enough process to get by, don’t obsess over the management aspect too often, and most importantly get involved.
In computer science, we have an adage: GIGO – Garbage In, Garbage Out.
If you, yourself, in person do not actively work at making your project a success, and all you do is spout out a few “as a, I want, so that” incantations once every two weeks to be put on a 3×5 index card, no amount of process is going to save you.
Technical debt is the same as financial debt.
Every time you say “I want it now”, you are creating debt. If you never allow your developers time and resources to clean up this debt, it will never be paid back. What’s worse, there is no software equivalent of a credit bureau, so we can incur as much debt as we like, more than can ever be paid back even if you went years without incurring any more. In this instance, you are both the lender, and the consumer. This is not a position you want to be in. Technical debt inhibits future growth in the same way that being shot in the face inhibits living. When every new feature must first traverse all the past mistakes, duplication, hacks, band-aids, and overrides you never made a priority, how fast do you think you’re going to move? Faster than your competitor? Safe enough to pass that audit? I don’t think so. Wise up, pay up. There is no free lunch.
You shouldn’t be the only “decider”.
Reject the notion of closed-door “requirements gathering” sessions. Embrace true collaboration, because you have no fucking clue how this shit works.
But HE does.
Software is incredibly hard to get right, and the people actually building it are the right people to discuss what you want, and the best ways to accomplish your goals.
Listen to your engineers, or you are in for a bad time, and you will not go to space today.
That’s all for now I think. In the end, I still love what I do, I just wish we could communicate a bit more openly and fix some of these things.
Love you all, and please don’t fire me.
I think it’s probably important to establish up-front, that the question of whether to teach everybody to code has been done to death. This guide assumes that you have considered these arguments, and are comfortable with your decision to give programming a try. Personally, I tend to fall into the ‘teach-everyone’ camp.
UPDATE: Okay kids, go to college. Don’t follow my example. You don’t have to study computer science to be a programmer, but you do need some kind of bachelor’s degree to be taken seriously. Things are starting to change, but for right now, college is essentially a requirement. This does not mean that you must study computer science to be a programmer. It certainly helps, but I know plenty of programmers with degrees in subjects other than Mathematics and Engineering.
Picking your first language
There is something special about your first language. Like a first love, it stays with you long after the infatuation period is over, past the breakup, and will continue to influence your decision-making for years to come.
I would suggest something in the dynamically typed space, because imposing a bunch of arbitrary rules seems pointless when you’re just starting out. C/C++ is too low-level, Java is too clunky, and lisps are too (con(fus(ing()))).
Joking aside, don’t agonize too hard over the decision, they’re mostly all the same once you get into them. There are some differences in syntax and the particular ideology behind the language, but for the most part they are all the same.
Whatever you do though, as a first language, please don’t pick PHP, VB, or SQL. These are so alien to all the others that they will forever warp your ability to grasp concepts which do not conform to the particularly strange way they are embodied in these languages. SQL is a great second language, but because it is super abstract, (so much so that it is considered declarative), and designed to deal with relational databases, that it’s really not a great language to start with. PHP is shit. Seriously don’t learn it.
Now go out learn it!
The task of learning to code is actually quite difficult, not because of a lack of available information as has traditionally been the case, but actually because there is now a metric fuck-ton of it, so your task is to sort through the crappy resources to find the pearls.
First things first, figure out your preferred learning style. If you find that you are more experimental, this is going to drastically change how you should approach the problem of learning to code.
My first experience with programming was out of a book: “Teach yourself BASIC” or some other similarly awful step-by-step learn something complicated through repetition with very little explanation style books that permeate the genre. I hated it, but for many people this was the way they learned. I suppose it was magical to be able to print things to the screen, but at 12 I didn’t really have the wisdom to appreciate that. Had I not revisited programming later in life, I would probably be doing something detestable like practicing law. Had I actually enjoyed BASIC, as Dijkstra would say, I would have been forever scarred, and my ability to program irreparably damaged. So, I guess it all worked out.
If you enjoy a guided tour of a programming language from start to finish, I would suggest the Learn ____ The Hard Way series by Zed Shaw. I have not personally read any of them, but I think he’s a great writer, and seems to genuinely care about his students’ ability to read and understand the lessons. Plus he’s sassy, and I like that.
College is Dead?
So, I have a funny story:
A few years ago, I volunteered at a career day for my little brother and sister. Elementary age kids. You’ve maybe done this yourself. It’s a casual way to introduce young impressionable minds to the careers that they may one day pursue. This is not really something that you’re expected to prepare for, or really take too seriously. I took it way too seriously. Some parents showed up in their uniforms, talked about what they do day to day. I prepared a PyGame demo and had the kids talk out the algorithm for binary search. I didn’t see those other parents’ presentations, but I’m pretty sure I crushed it. A kid asked for my autograph.
At some point during the first presentation, the teacher asks, “So, what should they study in college if they want to be programmers?”
Now, what I mean to say is: “It’s never been easier to get into coding, and if you want to try programming, why wait until college? Start when you get home if you want!”, what comes out is: “You don’t need to go to college!” The teacher is, of course, mortified by my statement and immediately goes on damage control. The message was more polished for the next class. I think college is really great if you want to broaden yourself as a human being, get some independence from your parents, and be surrounded by smart people who are into the same things you are.
If college is your thing, go for it. Go to college.
There was a lot of enthusiasm a few years ago around the concept of MOOC style offerings from major universities actually replacing the traditional college experience, but in general I think that for most people an in-classroom lecture style works pretty well. It’s certainly not the case that the ever-popular formula “anything + internet = instant_success” is always going to hold true. If you’re interested, try the free offerings from things like MIT Open Courseware before paid credential factories like Coursera.
Choose your own adventure Style
This is my favorite. Unlike advanced Mathematics, you can actually learn quite a few programming concepts without constantly being forced to understand the foundational underpinnings of the thing you’re actually trying to learn. This might seem trivial, but it’s extremely powerful. Not being forced to know about Boolean Algebra in order to understand that that “if (x > 10) do_stuff(x)” that you’re only going to do stuff when the value of x is greater than 10. Is x stored in a register, or allocated on the heap? Is do_stuff virtual? What’s the calling convention for that function? What are literally all of those things I just said? Don’t panic! You don’t have to know right now. This is due to a property that we programmers absolutely adore: abstraction. Suspend disbelief for a moment, learn the concept you are currently working on, and make a mental note to understand the wizardry that makes it possible.
This runs counter to the traditional educational paradigm where complex concepts build on top of simpler ones. Instead, most programming concepts tend toward elegance and simplicity. It’s true that to be a very good programmer you should strive to understand everything you possibly can, but the notion that you have to start from first-principles is incorrect, and potentially hazardous to your educational goals. As long as you’re curious, you can approach the task in any way you want.
Breadth-first: learn a little about a lot.
Here is a summary of a Bachelors degree in Computer Science.
- Learn a language.
- Learn some complicated mathematics of questionable value.
- Now learn another language, similar to the first.
- Now learn a third language.
I’ve probably glossed over some stuff about algorithms and data-structures, but that’s pretty much it. You get some solid exposure to a lot of things, but you probably won’t come away from the experience feeling necessarily ready to tackle any programming challenge life throws at you.
Depth-First: learn a lot about a few things.
This is definitely my preferred choice, because it’s incredibly easy to look like an absolute wizard compared to the first camp.
Oh, that’s cool, you know the first few chapters-worth of C/C++/Java like everyone else? Well I’m a D-lang black belt mothafucka, get on my level!
^^ This could be you. You’ll be writing 200 line code-haikus that outshine the competition because you actually know how to take advantage of the language. You’ll look like a rock star compared to someone who just knows the bare minimum required to pass. Learn the internals of the language, get into the culture that produced it, and dive as deep as you can into the most advanced topics you feel capable, and you won’t regret it. There isn’t really a degree plan to follow, but it has other benefits if you’re willing to invest the time.
No matter how you choose to approach programming, the most important thing is to never stop learning. Technology is in a constant state of change, and when you decide to pursue this as a career, the requirement of life-long learning comes with it.
Good luck, and please shoot me a comment if you found this rambling mess helpful in any way!
Hello. My name is Ross, and I’m a code addict.
Code addiction is a very serious ailment, affecting one out of every hundred software developers living today. Until recently, it was thought that code addiction was simply being good at programming, but there is a darker side; the ghosts of long-dead bugs have come back to addle the brain and corrupt the spirits of the unfortunate few. Some may delude themselves into thinking that this deviant behavior is merely attention to detail, or a dedication to our craft, however the cold hard truth is that it is an affliction.
If you fear that a friend or loved one may be a code addict, please, seek help immediately.
Signs of a compulsive coder include:
- Never admitting to having a problem, but rather constantly decomposing problems into several smaller problems.
- Kerning Dyslexia. The inability to read fonts which are not monospace.
- White-space obsession. Code-addicts like myself cannot read code which is considered “sloppy” by our own standards. His or her format-document key bindings will be worn smooth from overuse, and you will often find whole swaths of your code re-indented for “readability reasons”.
- Editor envy. Questions such as “Does your editor support macros?” and “Can I change the font and color settings?” will be commonplace. Resist the urge to let them install EMACS on your computer. It is almost certainly a mistake.
Sadly, there is no known cure for code addiction. To avoid inducing a fit of nerd-rage, ensure that your variables are named correctly, and that you follow best practices. The best we poor addicts can do is echo the following string to stdout, and hope for the best.
Compiler, grant me the serenity to accept the code I cannot change, Courage to change the lines I can, and the wisdom to know the difference. Writing one function at a time; Enjoying one cycle at a time; Accepting bugs as the pathway to production.