15 ms·

How to be a great software developer

263 points by buro9 13y ago

Bahamut 13y ago
I think one of the most important things is to learn for learning's sake - you should want to improve yourself and expose yourself to new things, especially if it makes you uncomfortable. The important thing is to challenge yourself (near) continuously, since specific libraries can come and go, but patterns can last longer.
buro9 13y ago
Two things always stand out to me: 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.
- buckbova 13y ago
  > Are you thinking before you touch the keyboard? 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.
  - davedx 13y ago
    With all due respect -- that is just how some of us work internally. We learn by experimentation, intuition and repetition. 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.
    - AnimalMuppet 13y ago
      Well... 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?
      - davedx 13y ago
        > 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.
        BugBrother 13y ago
        (Reading this a few days later in an open tab. :-) ) 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...
- joshdotsmith 13y ago
  > Are you thinking before you touch the keyboard? 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.
igvadaimon 13y ago
As much as I like this post because of beeing 'working horse' myself, I still believe that 'Rockstars' are very important when some brilliant solution is really needed.
dorkitude 13y ago
This post is great. 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.
markbnj 13y ago
I'm in an odd position on this one, because I agree with his list of desirable practices at the end, and disagree emphatically with his idea that writing something, anything, beats thinking about writing something 100% of the time. Much of the "quick" code we write in the real world ends up enshrined the minute it works, and never gets revisited or cleaned up. I once had to deal with a piece of data import code written by a predecessor who had moved on to management. He had a single 500-line try-catch block in which everything happened. When I mentioned that this wasn't the most maintainable or comprehensible approach, he simply replied that "it works." That statement, "it works", is a pretty low bar in software, imo.
- petenixey 13y ago
  I have to agree with that Mark. However there is (or a least should be) a difference between writing something and committing something. It can be hard to hold a manager off when you've got "functional code that's still a bit rubbish" but getting to that stage first before going over the top can (in my experience) massively accelerate development
  - markbnj 13y ago
    Agreed. The question is whether, in those cases where you begin with a "rough version," you are afforded the time for refinement? Most clients don't understand code, much less the difference between good code and bad. And very few of them are equipped to evaluate the long term costs of maintaining bad code. Hell, very few of _us_ are equipped to do that. So I remain very wary of this concept that time spent thinking is time that could have been better spent at the keyboard. Too often you only get one shot.
- CaRDiaK 13y ago
  Agree somewhat. This is also quite common. I think what new person forgets (I'm guilty) when looking at "rubbish" code is the context in which it was written. Was this done at 3am the night before it shipped? Was team morale incredibly low and this was the only guy left to write this? Did he/she not know of a better way? Did this start as a simple block and slowly accreted over time? Was he/she going through a rough patch but didn't have the time to refactor it. We've all had off days and spent more than another day unpicking what we did. Heck I look at code I wrote 12 months ago and could quite often tear it apart. This kind of thing just happens in places. Discipline is key. It's hard, but sometimes there has to be a balance or things wouldn't get done.
matwood 13y ago
You should aim for simplicity and over the years I have learned that simplicity is far more easily attained by time spent working and refactoring than hours of pure thought and “brilliance”. 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.
zimbatm 13y ago
tldr; things acquired by practice. 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.
- AdrianRossouw 13y ago
  Or you can just acknowledge that we are limited. all of us. Once you realize that, aiming for simplicity first is the obvious choice. http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...
agentultra 13y ago
I'm rather against the "working horse," methodology to software development. Maybe it's because I'm lazy but I'd rather work with tools and processes that let me achieve more with less effort. The "get it done," attitude is admirable but ultimately, I believe, leads to the very same duplication of effort that the author admonishes. 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.
- giulianob 13y ago
  Yep I'm learning that the more "lazy" I get the better quality software I release. You have to know which battles to fight and where cutting corners will save you a ton of time/bugs but won't hurt the end user too much. That's what makes a good programmer IMO.
bgschiller 13y ago
This guy keeps quoting his own tweets... from today. http://i.imgur.com/EePKQ.png http://i.imgur.com/EePKQ.png
- joshdance 13y ago
  He made the tweets to encourage sharing.
- petenixey 13y ago
  joshdance is right. I'm not undecided as whether it's obnoxious but I wanted to see how it worked out as a way to encourage sharing. I'd not seen it done before and so I wanted to experiment. FWIW so far it's not massively affecting sharing about 5x'd the rate at which people follow me on Twitter.
  - blt 13y ago
    It's obnoxious.
  - nebulous1 13y ago
    I liked the post but the quotes did come off as obnoxious. Still a good post though, so whatever.
  - robbs 13y ago
    I thought the quotes were good and I don't mind that they are your own tweets. I think you should remove the attribution and the date to make them more like pull quotes. A discreet, low contrast link to the tweet would let people share if they want.
- callmeed 13y ago
  "This guy keeps quoting his own tweets - bgschiller" - callmeed
gregd 13y ago
I for one loathe the term "Rockstar" programmer. For those of us over 40, it connotes someone who is young, with no familial commitments, can work 80+ hours a week, only needs RedBull and Mountain Dew to exist, has no loyalty and will burn out by the time they're 30. I for one run away from any company looking to hire a "Rockstar" anything. It's overused and abused.
- yukichan 13y ago
  I think it goes both ways. Younger engineers need to not avoid hiring old people because of fear of being a culture misfit and older engineers need to stop being self-conscious of their age all the time. Both can be a little bit more flexible and learn more about what other people like and appreciate the diversity that different ages can bring the workspaces. Both sides need to realize that the generalizations are all unrealistic. Young engineers aren't running around with pacifiers in their mouth pissing all over the floor and older people aren't losing their dentures in the snack area and falling asleep at their desk every day at 2pm dreaming about retirement. I say that as an engineer nearing my 40's.
- jmagoon 13y ago
  Can we also add "Ninja" and "Genius" to the list of abused recruitment buzzwords? And don't even get me started on "passion". (David Mitchell's take: http://youtu.be/Bz2-49q6DOI http://youtu.be/Bz2-49q6DOI)
  - Karunamon 13y ago
    I've got to disagree with you on the last one. Personally, I'd rather work with a developer (and hire, should I ever end up in such a position) someone who writes code because it's what they love to do first and because it happens to pay the bills second. Profit motive is powerful, but I'd argue that doing what you love beats all else. 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.
kordless 13y ago
> Not only is their output erratic but their superiority is aspirational and infectious. Their arrogance bleeds toxically into the rest of the team. 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.
raju 13y ago
Great post. If you want a even _further_ expanded version of this I highly recommend "Clean Code"[1] by Robert C. Martin, and I learned a few days ago that there is a follow up book, "The Clean Coder"[2] which I am yet to read [1] - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman... [2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers-ebook/dp/B0050JLC9Y http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
- mcguire 13y ago
  About The Clean Coder: http://maniagnosis.crsr.net/2012/03/clean-coder.html http://maniagnosis.crsr.net/2012/03/clean-coder.html
- avelis 13y ago
  Came here to say this. Glad someone did.
michaelochurch 13y ago
I like most of what he has to say, but I have to attack this: 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).
- e28eta 13y ago
  I'm coming from a large company mindset, but I disagree. We're working on projects that are too big for a single person, no matter how brilliant. Working well as a team is how we ship features. 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.
  - sheepmullet 13y ago
    A team can absorb the natural peaks and lulls that accompany high performance far better than an individual can. 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.
deleted 13y ago
[deleted]
- piokuc 13y ago
  IMHO a file over 200 lines is OK, as long as the functions in it are less than 50 lines long... That's one thing I cannot stand when reading people's code. Scrolling down to see the end of the function and then up again to see what that function was meant to do... It's a basic thing which all too often people writing coding standards documents or blog posts entitled "how to be a great programmer" forget about...
junto 13y ago
I'll leave this here from Joshua Bloch: http://www.youtube.com/watch?v=heh4OeB9A-c http://www.youtube.com/watch?v=heh4OeB9A-c How To Design A Good API and Why it Matters
zwegner 13y ago
I agree with most of the points of the article (finding a balance for testing, naming, writing readable code, etc.) I'm not a fan of the tone, though. I might consider myself a "rockstar" programmer, if not for the fact that it sounds incredibly douchey. At least I'm closer to that than a "workhorse". And yet I don't think I fall into the negative stereotypes he mentions... I guess that explains my reaction (not to mention the self-quoting of tweets). 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...).
- yawz 13y ago
  > not to mention the self-quoting of tweets Yes, I found it rather... strange.
- CmonDev 13y ago
  > "But I do wish there were more jobs that required real problem solving skills (and don't require a PhD...)." 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.
  - gvb 13y ago
AdrianRossouw 13y ago
> You should aim for simplicity and over the years I have learned that simplicity is far more easily attained by time spent working and refactoring than hours of pure thought and “brilliance”. 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/ http://daemon.co.za/2014/03/how-complexity-affects-software/ This is also really relevant: http://thecodelesscode.com/case/108 http://thecodelesscode.com/case/108
chasing 13y ago
Haven't we already had a great national discussion about the silliness of using "rockstar," "ninja," "guru," etc. when describing someone^? They're so vague... I'm a rockstar Hacker News commenter ninja guru. ^ [Edit: Except in the case when someone is actually a rockstar, ninja, or guru.]
kamaal 13y ago
On a side note, I asked a fairly successful tech professional->CTO->CEO what it took be a great programmer/engineer. Ironically the answer I got was not even related remotely to software in any 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.
- gtrak 13y ago
  I really like this comment. But I bet some folks gloss over a particular point of importance. 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.
rch 13y ago
Why on earth is an article on creating great software, written by a CTO, completely unreadable on a tablet (nexus 7)? I'm tempted to turn this observation into broader philosophical diatribe, but I'll refrain until I at least read the post somehow.
kenster07 13y ago
This blog entry is not very generalizable. It implies a certain kind of programming for a certain kind of business.
AdrianRossouw 13y ago
I agree with most of his points, and the parts we disagree on are more of a philosophical difference. 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.
ilcosrn 13y ago
Off-topic, but the each page of the site (not just the one linked to) makes my browser freeze for a couple of seconds and downloads ~3mb of crap. I don't think the ninja rockstar guru programmers are the only ones capable of writing a bubble sort and optimizing a page load.
hawkharris 13y ago
I appreciated some of the author's points, but his presentation was egotistical. The pedantically phrased, autobiographical tweets didn't add much to each section. It would have been more humble and interesting to include quotes by other talented programmers.
- gallamine 13y ago
  Perhaps you should find these interesting tweets and suggest them to the author? It's easy to criticize. Hard to be constructive.
  - hawkharris 13y ago
    I'd love to! As a starting point, I'd recommend John Resig, Jeff Atwood and Simon Peyton Jones. These are some of my favorite programmers who write about being developers. I think they do a wonderful job of describing the process and using metaphors to illustrate concepts. 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.
kenrick95 13y ago
Am I missing the point or is there really a mistake in this statement: "Remember, there are only two hard problems in computer science: cache invalidation, naming, and off-by-one errors. " ?
- simonw 13y ago
  It's a joke. Claiming two problems and listing three is an off-by-one error.
- sockgrant 13y ago
  It's a joke :) There's "two" hard problems: blah, blah, and off-by-one errors.
- kenrick95 13y ago
  Ah, now it all makes sense. Thank you for the explanation :)
yawz 13y ago
In my opinion "depth vs. breadth" balance is very very tricky to get right. We keep saying that a "fat T" is what we're going after. "Depth" is obvious but "Breath" certainly helps in architecting, in seeing the bigger picture, in being able to think out of a platform/language/framework's patterns.
anonymousdev 13y ago
Oh, yes, it's great to be a workhorse developer. You don't get any opportunities to use new technologies and improve your skills at work so you have a choice: program at home after work and in weekends or become useless in a few years and get out of the field or move into management if you're lucky. 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.
- anonsdev 13y ago
  Lol, Yup. It's funny he used the term "workhorse". I remember what happened to the workhorse in Animal Farm. A sucker is truly born every minute.
GarvielLoken 13y ago
Worse is better.
sockgrant 13y ago
A lot of software engineers don't realize that it's not about how much you work, but how strong you work when you work. It's about efficiency, good decisions, and total concentration. - 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.
- subb 13y ago
  That's all very hard to do when your code takes 10 minutes to compile. Yes it's C++.
  - sockgrant 13y ago
    I think this is the hardest part about doing this. But I try to find other productive things to do while things are compiling. - 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.
  - jamesaguilar 13y ago
    If your incremental builds take ten minutes that is probably the number one issue you need to fix at work.
  - lutusp 13y ago
    Have you considered running distcc on every machine in the building? It greatly speeds up compiles. http://manpages.ubuntu.com/manpages/precise/man1/distcc.1.html 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.
read 13y ago
I wish posts like this reduced their content to more concise descriptions so more people would finish reading them.
GFK_of_xmaspast 13y ago
"If there’s one thing that software developers care about, it’s becoming even better software developers." Observational evidence suggests otherwise.
weishigoname 13y ago
lucky to know
pyrrhotech 13y ago
1. collect paycheck. 2. save paycheck. 3. devote your time to more meaningful and/or pleasurable pursuits. 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.
- mattquiros 13y ago
  Nope, won't downvote, because depending on the team you're working with, you're right. I work in a company where I started off following the author's suggested actions for becoming a great software developer. However, I still ended up being the difficult co-worker, the "dressage horse" as the author put it. Just because I strongly felt about using classes instead of putting an object's attributes in a single, vertical bar-delimited string. It works, they say, and I'm over-engineering. 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.
- CmonDev 13y ago
  Most of the life will be spent at work and commuting to it. The best thing one can do is making work feel like less of a chore.
migidomingo 13y ago
Definitely going to keep all this in mind as I start my developer career. Thank you for this
vinceguidry 13y ago
Development is a creative act, everybody creates differently. I don't think I'd be any more productive at four hours a day than I am at my current 2 hours. Some days it's closer to 30 minutes. Rare days push 5 hours. 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.
known 13y ago
Every programming https://en.m.wikipedia.org/wiki/Language-agnostic https://en.m.wikipedia.org/wiki/Language-agnostic coder is a great developer IMO.
bubble_sort 13y ago
This might be a little bit off-topic, but... 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.
CaRDiaK 13y ago
Should be, "How to be a useful software developer".
JustinBrown 13y ago
I actually googled "Ronseal Code" thinking it was an established convention for writing code. facepalm Any good links out there for clean code best-practices?
- blevinstein 13y ago
  I did as well. To save everybody else from having to search, Ronseal is a maker of wood stains, and their slogan is "Does exactly what it says on the tin."

263 points by buro9 13y ago

I think one of the most important things is to learn for learning's sake - you should want to improve yourself and expose yourself to new things, especially if it makes you uncomfortable. The important thing is to challenge yourself (near) continuously, since specific libraries can come and go, but patterns can last longer.

buro9 13y ago

Two things always stand out to me: 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.

buckbova 13y ago
> Are you thinking before you touch the keyboard? 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.
- davedx 13y ago
  With all due respect -- that is just how some of us work internally. We learn by experimentation, intuition and repetition. 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.
  - AnimalMuppet 13y ago
    Well... 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?
    - davedx 13y ago
      > 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.
      - BugBrother 13y ago
        (Reading this a few days later in an open tab. :-) ) 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...
joshdotsmith 13y ago
> Are you thinking before you touch the keyboard? 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.

igvadaimon 13y ago

As much as I like this post because of beeing 'working horse' myself, I still believe that 'Rockstars' are very important when some brilliant solution is really needed.

dorkitude 13y ago

This post is great. 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.

markbnj 13y ago

I'm in an odd position on this one, because I agree with his list of desirable practices at the end, and disagree emphatically with his idea that writing something, anything, beats thinking about writing something 100% of the time. Much of the "quick" code we write in the real world ends up enshrined the minute it works, and never gets revisited or cleaned up. I once had to deal with a piece of data import code written by a predecessor who had moved on to management. He had a single 500-line try-catch block in which everything happened. When I mentioned that this wasn't the most maintainable or comprehensible approach, he simply replied that "it works." That statement, "it works", is a pretty low bar in software, imo.

petenixey 13y ago
I have to agree with that Mark. However there is (or a least should be) a difference between writing something and committing something. It can be hard to hold a manager off when you've got "functional code that's still a bit rubbish" but getting to that stage first before going over the top can (in my experience) massively accelerate development
- markbnj 13y ago
  Agreed. The question is whether, in those cases where you begin with a "rough version," you are afforded the time for refinement? Most clients don't understand code, much less the difference between good code and bad. And very few of them are equipped to evaluate the long term costs of maintaining bad code. Hell, very few of _us_ are equipped to do that. So I remain very wary of this concept that time spent thinking is time that could have been better spent at the keyboard. Too often you only get one shot.
CaRDiaK 13y ago
Agree somewhat. This is also quite common. I think what new person forgets (I'm guilty) when looking at "rubbish" code is the context in which it was written. Was this done at 3am the night before it shipped? Was team morale incredibly low and this was the only guy left to write this? Did he/she not know of a better way? Did this start as a simple block and slowly accreted over time? Was he/she going through a rough patch but didn't have the time to refactor it. We've all had off days and spent more than another day unpicking what we did. Heck I look at code I wrote 12 months ago and could quite often tear it apart. This kind of thing just happens in places. Discipline is key. It's hard, but sometimes there has to be a balance or things wouldn't get done.

matwood 13y ago

You should aim for simplicity and over the years I have learned that simplicity is far more easily attained by time spent working and refactoring than hours of pure thought and “brilliance”. 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.

zimbatm 13y ago

tldr; things acquired by practice. 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.

AdrianRossouw 13y ago
Or you can just acknowledge that we are limited. all of us. Once you realize that, aiming for simplicity first is the obvious choice. http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...

agentultra 13y ago

I'm rather against the "working horse," methodology to software development. Maybe it's because I'm lazy but I'd rather work with tools and processes that let me achieve more with less effort. The "get it done," attitude is admirable but ultimately, I believe, leads to the very same duplication of effort that the author admonishes. 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.

giulianob 13y ago
Yep I'm learning that the more "lazy" I get the better quality software I release. You have to know which battles to fight and where cutting corners will save you a ton of time/bugs but won't hurt the end user too much. That's what makes a good programmer IMO.

bgschiller 13y ago

This guy keeps quoting his own tweets... from today. http://i.imgur.com/EePKQ.png http://i.imgur.com/EePKQ.png

joshdance 13y ago
He made the tweets to encourage sharing.
petenixey 13y ago
joshdance is right. I'm not undecided as whether it's obnoxious but I wanted to see how it worked out as a way to encourage sharing. I'd not seen it done before and so I wanted to experiment. FWIW so far it's not massively affecting sharing about 5x'd the rate at which people follow me on Twitter.
- blt 13y ago
  It's obnoxious.
- nebulous1 13y ago
  I liked the post but the quotes did come off as obnoxious. Still a good post though, so whatever.
- robbs 13y ago
  I thought the quotes were good and I don't mind that they are your own tweets. I think you should remove the attribution and the date to make them more like pull quotes. A discreet, low contrast link to the tweet would let people share if they want.
callmeed 13y ago
"This guy keeps quoting his own tweets - bgschiller" - callmeed

gregd 13y ago

I for one loathe the term "Rockstar" programmer. For those of us over 40, it connotes someone who is young, with no familial commitments, can work 80+ hours a week, only needs RedBull and Mountain Dew to exist, has no loyalty and will burn out by the time they're 30. I for one run away from any company looking to hire a "Rockstar" anything. It's overused and abused.

yukichan 13y ago
I think it goes both ways. Younger engineers need to not avoid hiring old people because of fear of being a culture misfit and older engineers need to stop being self-conscious of their age all the time. Both can be a little bit more flexible and learn more about what other people like and appreciate the diversity that different ages can bring the workspaces. Both sides need to realize that the generalizations are all unrealistic. Young engineers aren't running around with pacifiers in their mouth pissing all over the floor and older people aren't losing their dentures in the snack area and falling asleep at their desk every day at 2pm dreaming about retirement. I say that as an engineer nearing my 40's.
jmagoon 13y ago
Can we also add "Ninja" and "Genius" to the list of abused recruitment buzzwords? And don't even get me started on "passion". (David Mitchell's take: http://youtu.be/Bz2-49q6DOI http://youtu.be/Bz2-49q6DOI)
- Karunamon 13y ago
  I've got to disagree with you on the last one. Personally, I'd rather work with a developer (and hire, should I ever end up in such a position) someone who writes code because it's what they love to do first and because it happens to pay the bills second. Profit motive is powerful, but I'd argue that doing what you love beats all else. 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.

kordless 13y ago

> Not only is their output erratic but their superiority is aspirational and infectious. Their arrogance bleeds toxically into the rest of the team. 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.

raju 13y ago

Great post. If you want a even _further_ expanded version of this I highly recommend "Clean Code"[1] by Robert C. Martin, and I learned a few days ago that there is a follow up book, "The Clean Coder"[2] which I am yet to read [1] - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman... [2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers-ebook/dp/B0050JLC9Y http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...

mcguire 13y ago
About The Clean Coder: http://maniagnosis.crsr.net/2012/03/clean-coder.html http://maniagnosis.crsr.net/2012/03/clean-coder.html
avelis 13y ago
Came here to say this. Glad someone did.

michaelochurch 13y ago

I like most of what he has to say, but I have to attack this: 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).

e28eta 13y ago
I'm coming from a large company mindset, but I disagree. We're working on projects that are too big for a single person, no matter how brilliant. Working well as a team is how we ship features. 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.
- sheepmullet 13y ago
  A team can absorb the natural peaks and lulls that accompany high performance far better than an individual can. 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.

deleted 13y ago

[deleted]

piokuc 13y ago
IMHO a file over 200 lines is OK, as long as the functions in it are less than 50 lines long... That's one thing I cannot stand when reading people's code. Scrolling down to see the end of the function and then up again to see what that function was meant to do... It's a basic thing which all too often people writing coding standards documents or blog posts entitled "how to be a great programmer" forget about...

junto 13y ago

I'll leave this here from Joshua Bloch: http://www.youtube.com/watch?v=heh4OeB9A-c http://www.youtube.com/watch?v=heh4OeB9A-c How To Design A Good API and Why it Matters

zwegner 13y ago

I agree with most of the points of the article (finding a balance for testing, naming, writing readable code, etc.) I'm not a fan of the tone, though. I might consider myself a "rockstar" programmer, if not for the fact that it sounds incredibly douchey. At least I'm closer to that than a "workhorse". And yet I don't think I fall into the negative stereotypes he mentions... I guess that explains my reaction (not to mention the self-quoting of tweets). 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...).

yawz 13y ago
> not to mention the self-quoting of tweets Yes, I found it rather... strange.
CmonDev 13y ago
> "But I do wish there were more jobs that required real problem solving skills (and don't require a PhD...)." 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.
- gvb 13y ago

AdrianRossouw 13y ago

> You should aim for simplicity and over the years I have learned that simplicity is far more easily attained by time spent working and refactoring than hours of pure thought and “brilliance”. 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/ http://daemon.co.za/2014/03/how-complexity-affects-software/ This is also really relevant: http://thecodelesscode.com/case/108 http://thecodelesscode.com/case/108

chasing 13y ago

Haven't we already had a great national discussion about the silliness of using "rockstar," "ninja," "guru," etc. when describing someone^? They're so vague... I'm a rockstar Hacker News commenter ninja guru. ^ [Edit: Except in the case when someone is actually a rockstar, ninja, or guru.]

kamaal 13y ago

On a side note, I asked a fairly successful tech professional->CTO->CEO what it took be a great programmer/engineer. Ironically the answer I got was not even related remotely to software in any 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.

gtrak 13y ago
I really like this comment. But I bet some folks gloss over a particular point of importance. 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.

rch 13y ago

Why on earth is an article on creating great software, written by a CTO, completely unreadable on a tablet (nexus 7)? I'm tempted to turn this observation into broader philosophical diatribe, but I'll refrain until I at least read the post somehow.

kenster07 13y ago

This blog entry is not very generalizable. It implies a certain kind of programming for a certain kind of business.

AdrianRossouw 13y ago

I agree with most of his points, and the parts we disagree on are more of a philosophical difference. 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.

ilcosrn 13y ago

Off-topic, but the each page of the site (not just the one linked to) makes my browser freeze for a couple of seconds and downloads ~3mb of crap. I don't think the ninja rockstar guru programmers are the only ones capable of writing a bubble sort and optimizing a page load.

hawkharris 13y ago

I appreciated some of the author's points, but his presentation was egotistical. The pedantically phrased, autobiographical tweets didn't add much to each section. It would have been more humble and interesting to include quotes by other talented programmers.

gallamine 13y ago
Perhaps you should find these interesting tweets and suggest them to the author? It's easy to criticize. Hard to be constructive.
- hawkharris 13y ago
  I'd love to! As a starting point, I'd recommend John Resig, Jeff Atwood and Simon Peyton Jones. These are some of my favorite programmers who write about being developers. I think they do a wonderful job of describing the process and using metaphors to illustrate concepts. 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.

kenrick95 13y ago

Am I missing the point or is there really a mistake in this statement: "Remember, there are only two hard problems in computer science: cache invalidation, naming, and off-by-one errors. " ?

simonw 13y ago
It's a joke. Claiming two problems and listing three is an off-by-one error.
sockgrant 13y ago
It's a joke :) There's "two" hard problems: blah, blah, and off-by-one errors.
kenrick95 13y ago
Ah, now it all makes sense. Thank you for the explanation :)

yawz 13y ago

In my opinion "depth vs. breadth" balance is very very tricky to get right. We keep saying that a "fat T" is what we're going after. "Depth" is obvious but "Breath" certainly helps in architecting, in seeing the bigger picture, in being able to think out of a platform/language/framework's patterns.

anonymousdev 13y ago

Oh, yes, it's great to be a workhorse developer. You don't get any opportunities to use new technologies and improve your skills at work so you have a choice: program at home after work and in weekends or become useless in a few years and get out of the field or move into management if you're lucky. 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.

anonsdev 13y ago
Lol, Yup. It's funny he used the term "workhorse". I remember what happened to the workhorse in Animal Farm. A sucker is truly born every minute.

GarvielLoken 13y ago

Worse is better.

sockgrant 13y ago

A lot of software engineers don't realize that it's not about how much you work, but how strong you work when you work. It's about efficiency, good decisions, and total concentration. - 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.

subb 13y ago
That's all very hard to do when your code takes 10 minutes to compile. Yes it's C++.
- sockgrant 13y ago
  I think this is the hardest part about doing this. But I try to find other productive things to do while things are compiling. - 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.
- jamesaguilar 13y ago
  If your incremental builds take ten minutes that is probably the number one issue you need to fix at work.
- lutusp 13y ago
  Have you considered running distcc on every machine in the building? It greatly speeds up compiles. http://manpages.ubuntu.com/manpages/precise/man1/distcc.1.html 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.

read 13y ago

I wish posts like this reduced their content to more concise descriptions so more people would finish reading them.

GFK_of_xmaspast 13y ago

"If there’s one thing that software developers care about, it’s becoming even better software developers." Observational evidence suggests otherwise.

weishigoname 13y ago

lucky to know

pyrrhotech 13y ago

1. collect paycheck. 2. save paycheck. 3. devote your time to more meaningful and/or pleasurable pursuits. 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.

mattquiros 13y ago
Nope, won't downvote, because depending on the team you're working with, you're right. I work in a company where I started off following the author's suggested actions for becoming a great software developer. However, I still ended up being the difficult co-worker, the "dressage horse" as the author put it. Just because I strongly felt about using classes instead of putting an object's attributes in a single, vertical bar-delimited string. It works, they say, and I'm over-engineering. 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.
CmonDev 13y ago
Most of the life will be spent at work and commuting to it. The best thing one can do is making work feel like less of a chore.

migidomingo 13y ago

Definitely going to keep all this in mind as I start my developer career. Thank you for this

vinceguidry 13y ago

Development is a creative act, everybody creates differently. I don't think I'd be any more productive at four hours a day than I am at my current 2 hours. Some days it's closer to 30 minutes. Rare days push 5 hours. 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.

known 13y ago

Every programming https://en.m.wikipedia.org/wiki/Language-agnostic https://en.m.wikipedia.org/wiki/Language-agnostic coder is a great developer IMO.

bubble_sort 13y ago

This might be a little bit off-topic, but... 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.

CaRDiaK 13y ago

Should be, "How to be a useful software developer".

JustinBrown 13y ago

I actually googled "Ronseal Code" thinking it was an established convention for writing code. facepalm Any good links out there for clean code best-practices?

blevinstein 13y ago
I did as well. To save everybody else from having to search, Ronseal is a maker of wood stains, and their slogan is "Does exactly what it says on the tin."