How to be a great software developer
peternixey.com
peternixey.com
I for one run away from any company looking to hire a "Rockstar" anything. It's overused and abused.
And don't even get me started on "passion". (David Mitchell's take: http://youtu.be/Bz2-49q6DOI)
I read a study once that found greater financial incentives are correlated with lower quality of work (might have been productivity), but I can't seem to mumble the right google incantation to bring it up again. I'll post it here if I come across it.
If you don't understand what the company is and what they're doing, then it's reasonable that you'll be at a disadvantage compared to people who did understand all that before applying for the job and likely applied because of that.
Passion is a double edged sword. I've known people who were passionate and misguided. Their passion to propagate their misguided viewpoint was a drain on the team and caused much drama.
I'm curious because I have been burnt out at work and decided to focus on those things I mentioned. I'm much healthier and productive overall. Yet if I went to an interview I wouldn't have hours of OSS commits on projects I worked on after work to meet most job requirements.
Absolutely not. There's a full spectrum here. But if some of your hobbies/leisure time relates to your work, you're going to be more valuable to an employer (assuming that doesn't get unhealthy). It's great if it's tangential, too. It's not about logging extra hours, it's about what gives you joy. Writing code could be one thing. Reading about new tech could be another. Or reading about related skills (management, design, marketing). If you truly love it, a higher percentage of your work time will be enjoyable, too (which means more productivity and better retention).
I certainly don't blame anyone for having a diverse life. But I have two great candidates, I'll always choose the one who loves their discipline enough that the read about it and noodle with it on the side.
Now in part I'm playing devil's advocate - there are podcasts you can listen to on a commute and you can read the odd blog post in a few minutes here and there and a relatively small amount of time can make a difference - but I still think people need to be realistic about what might fit with a particular candidate at a particular point in their life and what that actually means.
I'd rather work with people I can talk to about lots of different things, not just coding and work.
It could be just a semantic difference, but I would prefer someone who is steadfast rather than passionate--because most work isn't poetry, it's plumbing.
Some plumbers actually like plumbing. The act of creating things, reading about new techniques/materials/tools, solving the occasional interesting plumbing problem, working with customers and other contractors (and learning about THEIR needs so they can be a better plumber). If they are that kind of plumber, they go home and read Plumberblog.com, hang out with other plumbers talking shop, etc.
It doesn't correlate 100%, but the majority of stuff I've seen by the visibly 'passionate/excited' people does indeed end up far more of a mess than other code I've had the pleasure of working on.
It can indeed just mean someone is excited about the craft, but usually, from what I've seen, people are getting excited about learning new things, and almost by definition, they don't know how to use those things efficiently. Things = libs, coding techniques, etc. Those 'things' don't have to be 'new', just 'new' to the passionate individual. In those cases, the 'excitement' is coupled with "my first time doing X".
Passionate but professional is a better indicator.
So, when a company requires a passionate programmer for agile development, you know they're deep into bullshit and buzzwords.
I prefer to be passionate about tools on hobby project, understand the real implications and usage before commit to use it in project on the job.
But, for better or for worse, I am passionate about programming.
What was a Ninja? An expert martial artists, and incredibly skilled in his craft, which is no longer needed?
But then: enthusiasm and vigour is the domain of the young.
Also recklessness, poor judgement and looking good in very tight jeans. ;-)
Ask my wife ;o)
If such a person were to also work 80+ hours a week, then they would just get that much more done. But I know plenty of people who meet the criteria without working long ours.
I think some people who aren't "rockstars" try to correct for it by working longer hours, but I don't think that's what it's meant to imply.
Most productive engineer I've ever worked with was "older", had a kid, and a family. Easily as productive as the rest of the team combined.
You could be having the opposite effect by using that term in ads. My experience is anecdotal, myself and my peers, but I skip the rockstar/ninja/gurus ads pretty quickly unless the tech/description draws me back in.
Then just say you want those things! Why use meaningless fluff words that do nothing but attract a very specific demographic and turn the rest of us off completely?
It still sounds to me like you'll use and abuse me. If it all rolls up into this "bro" atmosphere, maybe that should die a fiery death?
Using these terms is doing IT a disservice. If we expect to be included in the boardroom, involved in making business decisions, it's kind of hard to take someone using high school terminology, seriously. Gag me with a spoon...
Rather than hire someone who felt that a job role needed to be sexed up for it to be interesting, I'd far rather employ someone who was comfortable in their own skin with who they were and how they earned their living and didn't feel the need to either big it up or have their ego massaged by someone else describing them in that way.
The thing he told me was that in all his experience, working with awesome people he found that "working things on paper", gave massive clarity in most projects. Human minds are not great at visualizing large stacks, diagrams and lists. Hence writing down things, simplifies things. In fact when you write things down. Draw that diagram, talk to yourself and refine your ideas on paper in a couple of iterations. You largely solve that problem of reuse, variable naming, problem identification. Agreed that some things demand you play with code a little to proceed further. Yet, planning on paper solves most problems which programmers face today.
Agile fashion unfortunately glorified many bad practices.
The more I pondered over that though the more I realized, how many bad practices came into software development with this quick development-deployment methodology. In the days of the past while you worked out some documentation before you started a project, you often probed, visualized and solved problems on paper. These days a lot of software is developed by the time you realize its actually bad. By then going back is not an option and you have live with it.
For me, there's a huge advantage in literally using tree-paper, either for code-reading, designing, taking notes, what have you.
It involves more of your senses, it's more tangible, every letter is written with more care and the medium is incredibly flexible (maybe I feel like drawing a circle on a whim, can't do that in emacs.)
It's better for scratch-pads than a text-buffer, imo.
Insights come more consistently and easily after iteratively marking up a printout. It's just fully-intuitive.
- Turn off e-mail.
- Turn off chat.
- Don't check hacker news. Or any website that is not for your current task.
- Don't let coworkers interrupt you.
- Get noise canceling headphones.
- Have a goal to get through, and apply yourself to it completely.
- Get very good at evaluating 3rd party code, then before you write code, see if there's a library/native code that will do the work for you.
- When you write code, if you _know_ the right way to do something, do it right the first time.
- If you're not _sure_ you know the right way to do something, then just get the code out into the editor. After it's functional, take a look at the code later and decide how it can be refactored. Refactor it immediately.
- Don't write any tough code when you're not at your best mental capacity. When you feel yourself mentally drifting on a hard task, put the code away and go work on easy features. Work on your hardest problems during your best hours.
- Write code comments
- Write tests
- Have a separate code checkout where you can work on another feature.
- Research the next thing you're working on.
- Work on improving the build time, while it's building :)
It's hard to always be doing something, but if you consciously make an effort to do it then it can have a large impact.
http://manpages.ubuntu.com/manpages/precise/man1/distcc.1.ht...
Quote: "Zeroconf: This option is only available if distcc was compiled with Avahi support enabled at configure time. When this special entry is present in the hosts list, distcc will use Avahi Zeroconf DNS Service Discovery (DNS-SD) to locate any available distccd servers on the local network. This avoids the need to explicitly list the host names or IP addresses of the distcc server machines. The distccd servers must have been started with the "--zeroconf" option to distccd. An important caveat is that in the current implementation, pump mode (",cpp") and compression (",lzo") will never be used for hosts located via zeroconf."
The above relatively new feature means that compiles will complete even if some local machines go on and off line during the work session.
It's under $1/GB
1) Are you thinking before you touch the keyboard?
If you have the mental model right for data structures, patterns, networking, caching, then you'll have fewer bugs. Get the mental model wrong, and one can treat a bug as a code smell, it probably indicates a fire that you've just not noticed yet.
2) As all bugs that have ever gone live have got past testing, Q&A and user acceptance... are you better at reacting to the unexpected (bugs) than the expected (testing)?
Bugs will happen, best to have great processes for when they occur.
I advocate insane measuring and monitoring which means thinking of instrumentation when you author code. This goes back to thinking, as a team and company one can fight the cargo cults with evidence. Monitoring and measuring dramatically reduces the time it takes to react to an incident, and guides which things should be tested in future.
I can't stand developers who "feel" their way through projects. Take the time to make a design document, whether it be a list of bullet points or pseudo-code. Something is better than nothing.
I often find it extremely difficult to write a design document for a system, particularly a system owned by somebody else. I have written design documents in the past, and they rarely end up describing the eventual system, no matter how hard I work to maintain and update them.
In my experience, software design and engineering is an iterative process, like gradually groping in the dark to determine the shape of a room. I cannot simply turn on the lights and take a photograph of the room at the start of the project.
Having said that, I completely agree that in principle it is great to start new projects with a complete design document, at least a functional specification. Accurate technical specifications are a rare, elusive beast, though.
If you don't know what you're trying to build, you probably aren't going to manage to build it. But in practice, you never actually know for sure, because things always change.
You should know how you're going to build it (the architecture). But in practice, my ability to be omniscient is very limited. As I implement it, I find out that my design/architecture was wrong.
Maybe the key factor is this: When you find out that the architecture is wrong, do you fix it? Or do you just hack it to get the next bit to work?
That's very project and organization dependent. Some projects are short lived prototypes (I'm working on one now) that are for internal use only, so it makes sense to try and get the damn thing finished without worrying too much about architecture.
Other projects are built to last, or have very high quality requirements, so you want to really get the architecture right, even if that means costly rewrites.
Imho the most important thing is to have a good design document for the data model. Partly because it often decides a lot of the structure of the code.
It is e.g. easier to rewrite code than realize that you lack some stuff you should have captured about customers years ago...
Agree completely. At this point it's part of our process to write design notes as the first part of a pull request.
My co-founder has been adamant that not enough time gets spent on the high-level architectural pieces. And I've personally found, after finally listening to him, that the more time I spend on architecture the less time I have to spend implementing.
I often re-factor, but there are some bits of code, which are a mess to look at - but they work. I look at the possibility of re-factoring, but why bother when, a) it works, has been for months b) the code doesn't change and is not likely to in the future. Aesthetically it could be a lot better. But it isn't really getting in the road, until it affects something else.
At no time am I ever behind on anything. I often solve problems without touching my laptop, sitting in my boss's office thinking things through.
I talk myself and my boss out of anything that looks like work. (He never gets the hint and insists on working long hours. I'm gonna have to break him of that habit someday.)
Things on my end run smooth because code isn't being committed every day and I verify that it's working before I let it go. I happen to be a team of one, so this is easy.
I've come to the conclusion that focusing on productivity is mostly a sham. Before you do anything, spend half a day thinking about the necessity of doing that thing, what consequences it'll entail, where it fits into your overall plan, what you'll do if your approach is wrong and you have to backtrack, ways to change your approach so it's more flexible, whether you might be trying to solve the wrong problem and the problem you're having is actually social. Nobody spends enough time doing this.
If you have to, use a checklist, and force yourself to do it before touching a text editor. Don't think with a cursor and keyboard, guaranteed you'll find yourself working prematurely. Better to fuck off than do that. I want to run a software business where more time is spent on YouTube watching cat videos or whatever than on writing code. Writing code's not cool, you know what's cool? Erasing code. That's cool.
Downvote away. Now, I don't dislike programming. As far as jobs go, it's definitely on the better side. But there's a lot of things I'd rather be doing with my time most of the time.
Of course my problem is about not being a good fit with the way the majority of the team chooses to work and build software and perhaps the solution is to just get the fuck out ASAP before I'm used to the mediocrity and acquire it. But the working relations definitely got smoother when I kept my mouth shut and just thought of the paycheck and used my time to go to the gym instead of refactoring their code.
My biggest problem with software development as a profession is that people don't think before they do it. I've found that a lot of people just hack away randomly with some code that approximates their idea of how it should work. It usually doesn't work, so they just change things aimlessly until it appears to. I can definitely understand this mentality, I've been there--it happens to me when I'm programming beyond my understanding. But I try very hard to recognize when this happens, and stop to think more. There's very little value in writing code that even the author doesn't understand. Accumulate enough of this code, and you get the typical horribly-designed patchwork mess that nobody can read, debug, or change.
To me, the ability to solve problems that you're not familiar with is paramount in importance for actual software engineering. If you're just building some CRUDdy business app that does nothing remotely complicated, OK. But bubble sorts and link shorteners? Come on, that stuff is simple. Maybe you never need to implement those specific examples, but as a placeholder for general problem-solving skill, it's a low bar.
Perhaps that's why the title refers to "software developer" rather than "software engineer". I don't really know. But I do wish there were more jobs that required real problem solving skills (and don't require a PhD...).
Yes, I found it rather... strange.
Isn't PhD just about having a bigger cook-book to use recipes from? It's not like they are coming up with a new theory for every problem.
For example, you're building a web application that has a signup process and the sales team uses an external CRM service to collect sales pipeline information. The programmer who shows up and does their four hours pulls out the usual libraries and writes the code to make it happen. The view fires up a few requests in an asynchronous task that updates some models and everyone is happy. However the sales team decides to change CRM services -- there's a shiny new kid on the block with features that would improve their sales process. The work-horse programmer gets the story and hunkers down. Four hours later there are a new set of tasks, a signup function, and hopefully a few tests.
The missed opportunity is that CRM software isn't terribly interesting and it should matter little when the web application signs up a new user whether you're talking to CRM A or B. I often find little scenarios like this that just add up over time. They're often missed because the focus is on getting something done for the next four hours/for the next sprint planning session/whatever. There's no real planning done beyond the next little bump in the road.
And so our solution is to use the same old tools and practices but simply hire more people to be work-horses.
I'd much rather engineer more robust RPC frameworks that can negotiate the protocols on their own so that a valid business decision to use a competing service doesn't cost me a couple of days of boring, tedious work. I'd rather just change a configuration line or two and sip an americano while reading the latest Vanity Fair in my garden.
So.. while a great article in many respects I would add that in order to become a great developer, in my opinion, you must refine your instincts towards laziness. You must become a connoisseur in methods by which you can avoid doing work. Being busy is not a virtue.
Be lazy because you don't want to do the same job twice.
Be impatient, and don't build tools that make you tell them things they should already know.
Fill your soul with hubris, and you will have to work on your code very hard so that nobody can find a fault in it.
A pretty smart guy, that Larry Wall.
However practice is important, I believe, and should be a part of any lazy programmer's regime.
A "working horse" may over-implement or over-engineer a system before any of its features actually prove to be useful. Those "fully implemented" features may later bite them in the ass when they need to pivot, or the requirements change.
* It sounds like the upfront cost is higher than the simple solution.
* I don't think changing the CRM is going to be a common occurrence, so don't optimize for it. YAGNI
* I doubt you'll get it right up front. The new CRM is going to require a couple tweaks to the code in addition to a config line change
* Maintainer needs to learn the custom layer you've built on top, whose documentation, googleability, and stack overflow support will be much less than the standard libraries.
To me, that's what I took away from the article's work horses. They focus their efforts on moving the product forward and maintaining clean code. Sometimes, that means forgoing the fancy engineering challenges.
I like this xkcd for trying to keep myself honest: http://xkcd.com/1205/
I apologize if my trivial example failed to illustrate my point for you.
My point is that part of being a good developer is learning how to avoid doing the same task more than once. Tactical thinking inevitably leads to doing the same things more than once. The best programmers I've had the opportunity to work with rarely had to re-write anything they had to written. They had internalized the paradigms, patterns, and practices to avoid writing code that is brittle to changing requirements. This is what I mean when I say part of being a good developer is learning to cultivate laziness.
Focus on the things that matter but learn to internalize ways to avoid making work for yourself.
Be careful that you don't spend so much time engineering frameworks that you never actually ship a product.
FWIW so far it's not massively affecting sharing about 5x'd the rate at which people follow me on Twitter.
[1] - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
[2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
This is where tests and egoless programming come into play. A lot of people seem to get mad when someone touches their code. It is almost like they think what they wrote is perfect, but the best programmers know that is never true. Great code comes from writing and refactoring code for readability first, and then refactoring for performance only after instrumentation.
Yup. It was Rich Hickey's presentation "Simple Made Easy" that finally allowed me to put it into words. I got so frustrated about only having a 1 hour presentation to link people to, that I ended up writing some notes to be able to refer people to.
This is the money shot I think.
http://daemon.co.za/2014/03/how-complexity-affects-software/
This is also really relevant:
There are hundreds of thousands of articles, books and sayings about code and being a programmer. When an author thinks beyond himself (and doesn't quote himself), he has exciting opportunities to draw from this pool of knowledge.
The example of a link shortener algorithm (what algorithm? generating new unique url?) and a bubble sort (is it bubble sort the algorithm? really?) is simply bad.
I would rather say that not the experience with specific problems makes developers good, but rather the ability to tackle and solve new problems. And I would say that a good developer given the task of writing a link shortener should be able not only to do it but also do it right.
I do agree that being a good developer requires striking the right balance between under- and over- -thinking, -complicating, -testing, ... In fewer words: common sense.
But most of all (as also noted in the article) it requires doing things the right way. The author might not believe it but there are tasks which require not only good looking but also performant code. Some of us also actually have to use some algorithms in our work. It all depends on the task.
I'm a rockstar Hacker News commenter ninja guru.
^ [Edit: Except in the case when someone is actually a rockstar, ninja, or guru.]
I'm more of a sinatra-type than a rails-type, and I don't really trust 'frameworks' that try to do so many things for so many people. I like my dependencies to have a much more clearly defined scope with fewer assumptions made.
I also don't think loc is an indicator of simplicity. Removing duplication as in his example, sure. But it being one line of code versus being 10 lines of code because it relies on a specific set of side effects, that may drift over time... not so much.
The gift of brilliant insight does not necessarily imply a negative impact elsewhere. I would agree this is probably an occasional side effect of having The Gift, but I think making a blanket blaming statement about these types of individuals is unfounded, and comes across as negative in and of itself.
That said, I think the rest of the post is absolutely bang on and wholeheartedly agree with it.
http://www.youtube.com/watch?v=heh4OeB9A-c
How To Design A Good API and Why it Matters
Couldn't agree more about the four hours per day piece. The best work I did in my career as a dev was the year I worked 20 hour weeks.
I wish we had a better way to measure and train specific parts of our brain. For example how much capacity you have in your short-term memory. How fast your analytical brain can combine things to find the best solution. How long you can stay focused on a single task.
If we where doing some kind of sport, we would use weight lifts to train specific muscles.
Once you realize that, aiming for simplicity first is the obvious choice.
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...
I'm tempted to turn this observation into broader philosophical diatribe, but I'll refrain until I at least read the post somehow.
Observational evidence suggests otherwise.
facepalm
Any good links out there for clean code best-practices?
There's "two" hard problems: blah, blah, and off-by-one errors.
It's really fun to make the first choice, because you either give up socializing and live a hollow life focused exclusively on programming, or you don't have time for physical exercises, cooking and eating real food(not junk) and other human routines that keep you healthy and you die at 40.
But never worry, because right before you'll leave this world you'll be able to say with immeasurable pride: "I've made someone else rich!".
Don't be stupid and care about interesting work and improving yourselves and especially don't boast about it because you make the workhorses feel bad(and FSM-forbid, even open their eyes). Shut up and keep your heads down because it will all be over soon.
It signals loud and clear that if you’re smart enough you choose when you work and what you work on.
What's so wrong with that?
In practice, I would prefer that a company use Github/Valve-style open allocation, and extend that sort of freedom to the whole team. People who can't justify their own salaries in an open-allocation environment (noting that a typical engineer is worth 3-5x under closed allocation and 10-20x in open allocation) are those you shouldn't be hiring anyway.
Often, brilliant, high-variance people are binary (or, at least, sporadic) in output, not because they have an attitude problem, but because they're neurologically built that way. Environments that favor (or, even, demand) reliable mediocrity shut them down and lose the ability to hit the high notes.
The best way to work with such people is to give them an R&D environment where they direct their own work and career. They know what they're doing, and they make more of a profit with the hits than they lose on the misses. But I'm not convinced that anyone who's smart enough to be a decent programmer shouldn't have the same freedom (open allocation).
Being predictable in our output is important to the business, because they have plans for the project/feature that we'll work on next. There are marketing and customer support teams working with us who also value our ability to deliver what we've promised, and when. There are customers who need features by a specific date.
I think the best engineers are the ones who improve the output of the entire team. Just like a good manager can improve the productivity of their engineers.
If you need everybody to be operating at 100% week on week in order to hit your deliverables then you have over promised and introduced an incredible amount of risk into your projects.
As a manager, if you care about the productivity and general well being of your team then you will be promising a max of around 70% team effort. Managing the expectations of other teams and departments is part of being a decent manager.
Spend two weeks sharpening the ax and then another cutting down the tree? No, the average company would rather you spend six, or even twelve, weeks chopping away with your blunt ax.