How to be a great software developer(peternixey.com)
peternixey.com
How to be a great software developer
http://peternixey.com/post/83510597580/how-to-be-a-great-software-developer
146 comments
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)
And don't even get me started on "passion". (David Mitchell's take: http://youtu.be/Bz2-49q6DOI)
I'll disagree with the last one. Whanever I hire for, I always look for "passion for the craft" - whether it's design, code, marketing, or whatever. A great question is "What's the last book or blog post you've read in your field that got you excited?" If people love what they do enough to explore it in their off-time, they'll (usually) be a cut above the rest... And they won't get bored/tired of their work as soon or as easily (assuming you can provide interesting work).
In the context of the parent article, I have spent ample time cleaning up the code and mess of people who get excited about something, then about something else, and never complete what they begin.
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.
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.
I don't think being excited/passionate about something means "messy and can't complete projects" - that means they are perhaps excited about the wrong thing.
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.
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.
"I don't think being excited/passionate about something means "messy and can't complete projects" - that means they are perhaps excited about the wrong thing."
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".
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".
To much passion is a bad sign; such people can develop emotional attachments to their code that aren't very professional.
Passionate but professional is a better indicator.
Passionate but professional is a better indicator.
Passion is in stark contrast to egoless programming, which (aww, shucks!) is a pillar of the agile methodology that those who want passionate programmers pay lip service to.
So, when a company requires a passionate programmer for agile development, you know they're deep into bullshit and buzzwords.
So, when a company requires a passionate programmer for agile development, you know they're deep into bullshit and buzzwords.
Does that make it a negative if you're time away from work involves family, outdoor activities, DIY projects, etc? I think that what you are saying is what most people look for. Someone who writes code for a living and then goes home to write code to relax. That generally fits the young, unmarried/no kids, recent college grad stereotype.
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.
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.
I'm 30 (dunno if that's "young"), married, and write code to relax... kids might change that though (or at least change how much time I have to relax!). Not that I think everyone needs to work the same, mind you...
Kids don't change that. My little girl is 5 weeks old and I find much solace behind my editor during quiet times :) It's reinvigorated with the hope of whatever I learn I can pass down in the future.
5 weeks is a piece of cake. Years 2-18 is where my spare time evaporated.
I totally agree. Coding while monsters from cartoons and video games are growling in the background.
Or when my 4yr and 6yr old are fighting and a teenager is playing loud music.
Oh I have a 3 year old boy too but I expected the new arrival to really kill any time I can spend on myself.
I have a 14-month-old son, and I'm in the same boat. I watch him while my wife goes to night school, and after he goes to bed, I have a few of my most calming and productive hours of the day.
Thanks for the hope! Less time to code is probably the piece of it I'm looking forward to the least.
What the kids do is introduce the "distraction factor"... Right when you're really in the middle of that groove... your baby will waddle in the room and try to kiss you or play with the noisiest toy in the solar system... Then she'll drop it and the dog with run off with it which will cause crying and boom... mood halted...
"Does that make it a negative if you're time away from work involves family, outdoor activities, DIY projects, etc?"
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.
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.
I have two young kids and while it's changing as they get older I hardly have time for ANY hobbies, let alone enough for a range of activities of which this might be one. You say it's not about logging extra hours but in reality that's what it comes down to - you can't read books, write code, explore libraries and so on without time.
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.
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.
Personally, I prefer well rounded candidates with decent life experience (because we are biased to what we see in ourselves).
I'd rather work with people I can talk to about lots of different things, not just coding and work.
I'd rather work with people I can talk to about lots of different things, not just coding and work.
About that passion... [1]
[1] http://devblog.avdi.org/2014/02/10/the-passion-gospel/
[1] http://devblog.avdi.org/2014/02/10/the-passion-gospel/
[deleted]
I consider myself passionate about programming, and I think passion leads nowhere. A little (or perhaps a lot) less passion would allow me to concentrate on the actual product, instead of seeing an ugly architecture everywhere, or the sheer amount of repetitiveness of imperative programming where functional programming would be a cleaner approach, or tests everywhere when a smarter type system would be better and faster at catching bugs.
But, for better or for worse, I am passionate about programming.
But, for better or for worse, I am passionate about programming.
Look for passion AND self-control. We do not want somebody who keep using wrong tools for the job.
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.
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.
Reading this post made me thing about the term 'Ninja', and when the OP was discussing workhorses, I thought "why do we use the term Ninja? it isn't like Ninjas are out winning wars anymore."
What was a Ninja? An expert martial artists, and incredibly skilled in his craft, which is no longer needed?
What was a Ninja? An expert martial artists, and incredibly skilled in his craft, which is no longer needed?
A ninja in modern war, would be like a punch-card coder working on a windows app..
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.
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.
I agree that passion is valuable, but expect me to be passionate about coding and solving problems, please don't expect me to be passionate about your company before I even fully understand who you are and what you're doing.
Passion for continuous improvement is important as well.
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.
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.
For quite many companies there are people who are passionate about that company and their goals even if they don't [yet] work there. E.g., some high-profile programmer posts about Oculus Rift impled that, and there are many niche-cases for specific business areas.
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.
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.
I've always done research, but there's usually a lot of hugely relevant information that's not going to be very publicly available. Oculus is a bad example - most companies are not high profile, in a space with few other significant players that has been romanticized by sci-fi media for decades. Of course, there are always going to be idiots blindly excited by what they imagine, but those aren't the good hires - the best hires learn what they can, then pick the best option, then pursue it passionately.
The research you're looking for is probably from Daniel Pink. He found that for creative tasks, higher financial incentives led to lower quality output. For routine, standardized tasks, financial incentives work well.
Is this what you were looking for? [1] When looking at a financial reward as a motive for great work, a study found this works great for work that is very monotonous/tedious, and horrible for work that requires a lot of thinking. In fact, when offered larger and larger rewards based on better work for the more mentally strenuous work, the quality of work seemed to go down.
[1] https://www.youtube.com/watch?v=u6XAPnuFjJc
[1] https://www.youtube.com/watch?v=u6XAPnuFjJc
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.
Maybe it does to some people, but I use the term "Rockstar" to connotate:
- highly productive
- gets features shipped (avoid analysis paralysis)
- features rarely have bugs
- features rarely have to be refactored when we scale
- code is easily maintained by other engineers
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.
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.
> I use the term "Rockstar" to connotate: - highly productive - gets features shipped (avoid analysis paralysis) - features rarely have bugs - features rarely have to be refactored when we scale - code is easily maintained by other engineers
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?
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?
I'm not sure if you're a recruiter or work with bringing new talent into the team. But when you say "I use the term "Rockstar" to connotate", don't forget many might not interpret it that way.
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.
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.
"Rockstar" along with "Ninja" and the like feel like they spring from a deep seated insecurity about what the organisation and the people there do and it's value and appeal.
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.
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.
Exactly. I've seen multiple companies that have their developer ads filled with words like "rockstar" and "ninja" while their other postings (accountants, salespeople, whatever) sound like proper adult jobs. Doesn't exactly scream "developers are taken seriously here".
Yep, there are few adverts for an Accounts Payable Wizard or a Contract Law Guru.
Yes, I'm always intrigued by that term. So they want a programmer who is into sex, drugs and rock and roll and shows up to work once in a while, always late and never sober?
Right gregd, life is a marathon, not a sprint. It takes endurance to make it beyond 30 as a developer. And, lets face it, we get better, the longer we develop.
But then: enthusiasm and vigour is the domain of the young.
But then: enthusiasm and vigour is the domain of the young.
> But then: enthusiasm and vigour is the domain of the young.
Also recklessness, poor judgement and looking good in very tight jeans. ;-)
Also recklessness, poor judgement and looking good in very tight jeans. ;-)
I still look good in tight jeans thanks to running and swimming.
Ask my wife ;o)
Ask my wife ;o)
Can't agree more. Developers are the _least_ rockstar-like people. In fact they are the polar opposite. The greatest developers I know have long beards, quiet, humble and do it for the love of the craft. Rockstar often conjures up an image of a douchey don't-care-loner guy.
An older person can be a rockstar too ... it refers to your ability to crush code, not your ability to ingest red bull. Maybe the word has gotten a bit of negative connotation, along with brogrammer, but it's essentially a good thing at heart.
"Crushing" code is another term that makes my hair stand on end. Pretty much use the word "crush" or "disrupt" in any description and it's another red flag for me to move on and not look at your job posting. Maybe I'm just an old fart that will soon be yelling at you kids to get off my lawn. I don't know.
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...
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...
If it's just a thin layer of whimsy over a serious business culture, I don't consider it a bad thing. If it is a process of "use and abuse" I agree that it's a bad thing.
Probably the true rockstars of a team are, for the big part, all "older people". Experience is a great boost
I consider myself a Guru because I'm old and I don't care about work, materialism or consumerism.
Axl Rose is a rock star too.
Might want to see how things work out for most people with that loyalty bit
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.
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.
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.
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.
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.
- 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.
That's all very hard to do when your code takes 10 minutes to compile. Yes it's C++.
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.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.
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.
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.
- 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.
If your incremental builds take ten minutes that is probably the number one issue you need to fix at work.
Every new dev machine should have an SSD.
It's under $1/GB
It's under $1/GB
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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?
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?
> 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.
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.
(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...
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...
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.
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.
I have my own codebase at work, for the in house database. Some of the time it gets written well, other times things are rushed and done to a poor standard.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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...).
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...).
> not to mention the self-quoting of tweets
Yes, I found it rather... strange.
Yes, I found it rather... strange.
> "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.
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.
No, it means you've pushed the boundary out slightly.
http://matt.might.net/articles/phd-school-in-pictures/
http://matt.might.net/articles/phd-school-in-pictures/
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.
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.
I'm probably misunderstanding you, but your example seems like the whole reason Rockstar programmers can be harmful to a team. I agree completely about laziness and looking to the future, however.
* 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/
* 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/
You're absolutely right. It makes far more sense to make the tactical decision to simply change the necessary code to work with the new CRM. I, and I suspect most of us, make the very same decision every day. When your goal is to build a product and ship then tactics, as in chess, will win you the game > 90% of the time.
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.
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.
An idiom that dovetails nicely with laziness is YAGNI (You Ain't Gonna Need It.)
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.
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.
"I'd much rather engineer more robust RPC frameworks..."
Be careful that you don't spend so much time engineering frameworks that you never actually ship a product.
Be careful that you don't spend so much time engineering frameworks that you never actually ship a product.
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.
This barely known programmer called Larry Wall said, many years ago, that the three virtues of the programmer are laziness, impatience and hubris.
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.
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.
refining instincts to tend towards laziness - i.e. reading vanity fair in the garden - seems to be the antithesis of experimentation and practice and supportive or a 'I've seen it all before mentality'. both of these are very bad for sw developers.
Perhaps it is best to spend time away from the keyboard once in a while and open your mind a bit. Ideas don't spring forth from a vacuum.
However practice is important, I believe, and should be a part of any lazy programmer's regime.
However practice is important, I believe, and should be a part of any lazy programmer's regime.
This guy keeps quoting his own tweets... from today.
http://i.imgur.com/EePKQ.png
He made the tweets to encourage sharing.
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.
FWIW so far it's not massively affecting sharing about 5x'd the rate at which people follow me on Twitter.
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.
It's obnoxious.
I liked the post but the quotes did come off as obnoxious. Still a good post though, so whatever.
"This guy keeps quoting his own tweets - bgschiller" - callmeed
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-Craftsman...
[2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
[1] - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
[2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
About The Clean Coder: http://maniagnosis.crsr.net/2012/03/clean-coder.html
Came here to say this. Glad someone did.
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.
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.
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.
> 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/
This is also really relevant:
http://thecodelesscode.com/case/108
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:
http://thecodelesscode.com/case/108
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.
Perhaps you should find these interesting tweets and suggest them to the author? It's easy to criticize. Hard to be constructive.
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.
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.
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.
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.
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.]
I'm a rockstar Hacker News commenter ninja guru.
^ [Edit: Except in the case when someone is actually a rockstar, ninja, or guru.]
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.
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.
> 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.
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.
I'll leave this here from Joshua Bloch:
http://www.youtube.com/watch?v=heh4OeB9A-c
How To Design A Good API and Why it Matters
http://www.youtube.com/watch?v=heh4OeB9A-c
How To Design A Good API and Why it Matters
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.
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.
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.
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.
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.
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_...
Once you realize that, aiming for simplicity first is the obvious choice.
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...
I wish posts like this reduced their content to more concise descriptions so more people would finish reading them.
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.
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.
I'm tempted to turn this observation into broader philosophical diatribe, but I'll refrain until I at least read the post somehow.
Every programming https://en.m.wikipedia.org/wiki/Language-agnostic coder is a great developer IMO.
[deleted](1)
"If there’s one thing that software developers care about, it’s becoming even better software developers."
Observational evidence suggests otherwise.
Observational evidence suggests otherwise.
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?
facepalm
Any good links out there for clean code best-practices?
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."
This blog entry is not very generalizable. It implies a certain kind of programming for a certain kind of business.
Definitely going to keep all this in mind as I start my developer career. Thank you for this
Should be, "How to be a useful software developer".
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. " ?
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.
Worse is better.
lucky to know
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.
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.
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.
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).
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).
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.
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.
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.
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.
I for one run away from any company looking to hire a "Rockstar" anything. It's overused and abused.