Actually 1,000 lines of code a week is quite a lot. Of course it depends on language / technology stack, I'm speaking from Rails / JavaScript programmer point of view.
Yes. And this: "Your 1,000 lines should be the essential core that enables a team of programmers to write another 10,000 lines effortlessly."
If you're writing critical core stuff like that, you better spend a lot more than a week on it. I can't imagine working on anything where the team regularly writes 10,000 lines a week. Prototypes by one person can easily grow at 1kLOC per week for a short time, but that's a special case.
I'm a senior engineer who has written over 150k loc the past month :( . I have had to tackle some difficult problems that allowed the other engineers to keep moving.
My workaround so far has been to do most of the critical work during after hours or before everyone comes in the office, since my primary role during regular hours is to keep everyone unblocked. It isn't sustainable though, and I only do it at the moment because we are in crunch mode - 'tis the startup life.
Since no one in HN has called you out, let me do so. You sir, are a liar. 150k LOC? GTFOH! Seriously, how many did you throw out? BS! Being that you are on HN, you definitely have free time, what's your github?
150 000 lines of code / (10 hours * 5 days * 4 weeks) = a sustained 750 lines of code an hour? That's impressive. Can you share a bit more about how you manage to achieve such productivity for those of us who aspire to be like that?
750 LOC/hour on average? The secret to that is either having a very loose definition of code (e.g. counting generated files, copy and pasting huge amounts of boilerplate, etc) or a very loose definition of honesty. Nobody is that productive, especially not working 10 hours a day. If I do 750 LOC in a week, that's a good week!
In my experience aspiring to this would be a mistake.
You can pull off very high production numbers for a while [under whatever metric you choose] before you start babbling in a corner somewhere, but invariably i's mostly crap and you'll end up replacing every 100k lines with 10-20k lines later, but this time it will be well though out, tested, and maintainable.
I've met a few people who have convinced themselves this isn't true, but nobody who has managed to convince anyone else.
So you can paint yourself into a corner where all you can do is crank as fast as your tooling allows, but it's like deficit spending, it will cost you more in the long run than doing it right would. Of course, if having a long run at all to worry about this depends on your current output, crank away.
I have an excellent command of JavaScript and AngularJS, which allows me to focus on the problems themselves and not get fussed up with language subtleties...usually. I also have been working 70+ hour weeks for the past month, often 75 hours. There have been multiple times I had to shut my brain for the night because my focusing ability starts to deteriorate if I code too long. I also try to get a good night of sleep most nights - 7-8 hours prove optimal for me, although I often end up with 6.
A good portion of those loc have been complete rewrites based on existing code to clean it up and meet unforeseen changes in requirements that nobody planned for. Honestly, the amount of code I pumped out is a miracle, I'm hoping I don't get stuck in such a situation again at my current job.
And don't forget- its not nonstop; he's managing others during the day and setting his fingers on fire before & after work, its probably under 4 seconds per line!
Which, as long as you never under any circumstances have to actually read, build, run, or debug any of the code, is totally do-able.
Even if this physically impossible feat of coding were true, that's 150,000 lines of code to debug, written while tired. Enough to set a full engineering team back for a year.
I work with Angular and Javascript as well. I don't think you should count the html code, if that is what you did. Count the javascript-code only and see how many lines you write in a week. And if the number still is as high as you've said I must wonder what kind of system you are building? Normally you rewrite everything that is repetetive into services/controllers/functions to keep the line count down. There was a talk recently from Google about some large application they had written in Angular, the problems they ran into and what they learned from that. They provided some line counts and it wasn't millions of lines even for them and they still had a team of something like 10-20 developers.
Others are downvoting you, possibly bc they think you're exaggerating, but I just find your claims to be curious and would be really interested in meeting you. That is, if you ever have time to meet other people. Let me know, contact info is in my profile.
The claim was he did this mostly while others weren't in the office. If you assume they work a straight 8 hours (and why would they at crunch time) that leaves 14hrs/day to eat/sleep/work. 10/5 isn't so unreasonable approximation
But hey, another way to look at it. 150,000/30 = 5000 lines/day. At 16 hrs/day, that is 312.5 lines/hour, or 5 lines/minute non-stop.
Not killing myself, and leaving the typos in that wouldn't affect compilation, I generated the code below in 36 seconds; I knew what I was going to program ahead of time - there was no thinking involved. I honestly could have typed faster, but I also didn't want to type faster than I could sustain for 16 hours nonstop. I haven't had my coffee yet, so that is a factor.
So that is right at the target rate. I don't think I could maintain that 16/7 for real problem. I'm going to have to stop to think, to look up things, to make mistakes, to write tests, to document. Unless we assume I am perfect, I'm going to have to spend time debugging. This is for a stupid Euclidian distance function, whereas the claim was it was difficult, critical code. And the claim is not 16/7, it is "before/after" office hours.
import math
def distance(x,y):
""" compute striaght line distance between x and y"""
return math.sqrt(x**2 + y**2)
Worth adding this doesn't even find the two dimension distance between two points, it finds a hypotenuse length using the Pythagorean theorem and doesn't accept two points as parameters (unless they are on a number line, and in that case math.abs(x - y) would be the correct code).
That... and I shiver to think of the amount of buggy code being churned out. 150k lines of crappy code isn't something to be proud of.
More code = more points of interaction = more bugs.
Caveat: This is assumption based. I assume that much code is due to "quantity not quality". Boilerplate code, copy/pasta, 10 lines of actual code, 100 lines of test, etc
I read the essence of that statement without the same time constraint applied to it. i.e. the type of 1000 lines you should be working on each week is the type (systems code) that enables (application) programmers to write the rest of their code effortlessly.
e.g. Rails core (system) vs people who use Rails (applications).
It very much depends on whether it's new code or maintenance mode as well. I've managed to put out 2kloc of MFC C++ over the past two weeks for an internal test app, but that's very unusual and my maintenance work is more like 100 loc a week.
I think the most extreme of this was a colleague of mine years ago who spent two weeks bug-hunting and eventually removed a single wrong minus sign. Vital work that this metric is completely useless for.
Same here.
The German Wikipedia page for LOC (http://de.wikipedia.org/wiki/Lines_of_Code) says that usually 10-50 LOCs per day are normal which would be 70-350 LOC per week.
Still it's not a metric. I know people that use ruby in a way that every 6-lines method of mine, could be 1 (hard to read, sometimes extremely cryptic) line of theirs. I'm not sure you can measure, not even using third party apps.
Agreed. As I get more experienced with Django (and a greater understanding of things like class based views) my code gets a lot more concise. I just updated some code from 6 months ago. If I were to replace it, it would probably be half as many lines, and more reliable.
1,000 lines are probably not as much as you think. For web developers, if you included HTML, CSS, JavaScript, CGI language and SQL you can easily get over 1,000 characters in a week. (That's only about 25 lines an hour for 8 hours/day 5 days/week.)
What kind of projects do you work on? I'm sure the experience differs a lot between people working on important, complex legacy projects, and people developing consumer mobile apps for photo sharing etc.
Exactly, that was my point. If you're starting a simple consumer product you'll write lots of code quickly. When working on something complex you need to consider how your changes will effect every aspect of the product.
Exactly. When I was working on a payroll system it could take a day to change a modify a few lines and test all the various scenarios before releasing. The cost of making a mistake was large.
"... From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger."
It depends on what career trajectory a senior developer is. If he is destined to become a specialist, then this article is spot on.
If instead he dreams of becomming a manager or architect, then he would actually not be coding the most complicated parts, and make sure to keep himself off the critical path of the project, so as to free up his time, so he can spend his time helping his colleagues and clearing the rocks in their path.
Also as a manager or architect, you better get used to constant interruptions, degrading the quality of code you can generate. So think hard before assigning that critical section to yourself.
For a manager, I agree. An architect should write the most complicated, not the least complicated, part of code. This is assuming that the architect is the most experienced developer on the team.
This doesn't include paper architects, which are pretty much salespeople.
I would like to hear other people's thoughts on this - this is the way that I have always handled projects.
I suppose whether or not I agree depends on what you mean by complicated: there's complexity of an algorithm implementation and there's complexity of program structure.
I would think that you'd want an architect to work on non-tight-loop, core-to-the-control flow complexity, and leave the optimization of tight loops and such to people with more time to focus on the details of that (eg, what processor is being used), and instead work on the complexity of the control/data flow abstractions, which is what he already knows the most about, having designed their architecture.
This also keeps his role as central organizer of the code and flow through it, rather than having his time sidetracked (partially) by other concerns.
That is how I have it as well. With our projects usually the architect would write the framework of the product at the beginning of project, almost being the only developer on the project.
As other developers start getting on the project he guides them where their code should live, and he start to disengage writing and serve more in a guiding role.
I see the architect role in software development pretty much the same as a architect of a building. He/she will be in charge of the big picture and let others do most of the implementation and deal with small details, unless it's a crucial detail that the construction workers/developers needs help on.
OK, since a lot of comments here are discussing Software Architecture in general, I would like to ask a question that I've been wanting to for a long time: As a Developer with ~2 years of experience and desiring to be a Software Architect, how do I get there? And by that I mean: how do I develop the talent to design large/complex/distributed software systems, when I'm actually really working on much smaller things on a day-to-day basis? Is it all just something I have to learn in my free time? If so, then how should I go about it?
IMHO, there's no such thing as a Software Architect. Take this for what you will, but people that label themselves as being architects are an instant red flag, as that's usually corporate slang for I'm incompetent, but I can draw diagrams and have meetings.
The industry is simply separated in developers that suck (because they lack either the experience or the ability) and those that don't and that are thus capable of making good decisions.
As to how to get there, there's no simple recipe, but in general you simply have to (1) read a lot, like books, papers, other people's source code and (2) you have to get burned by a lot of bad choices you've made and learn something from those mistakes. Both have something to do with getting out of your comfort zone.
I have to disagree: There certainly are people who can keep (very) large systems in their minds and refine and extend them, but they are very rare and most of the people who might call themselves "Software Architects" are not.
It might be said that the definition of "size" for a computer system is exactly the degree to which it requires "architecture" to make it.
Under that interpretation one way to try to become a "Software Architect" is to study large systems and how they succeed or fail at their intended purposes.
Well, I can tell you easily how a large system (to the degree that it requires a architect to understand) get successful: They don't.
Successful systems may get large, and as a general rule, large systems do not get successful. Once in a while a large system is so well written that it fits inside the head of anybody, and it has a chance of success. You can never get one of those later if there's interference of people that do not code directly.
In my opinion, what works in the small also works in the large and even though there may be caveats with this rule (e.g. synchronous communications vs asynchronous ones that may introduce non-determinism), if you stick to the rule of building simple components that do one thing and do it well and them combine them to build bigger components that are still simple (in the non-entangled sense), then you'll definitely do a good job. But that's easier said than done because ...
There are two types of problems here:
1. doing design mistakes because you make a decision that you never took before and then you get burned by it - as an example you might introduce unwanted cyclic dependencies between your components and if you're talking about different address spaces, then things can get really problematic, or you might introduce concurrency concerns (like in the communications between components) that could be avoided - problems that you won't avoid until you get burned by them.
2. some projects have an incredibly complex business logic - I'm working on such a project right now and the business logic is like a freaking fractal. Being so complex and the architecture being based on micro-services, the downside is that people are only willing to understand only as much as they need to for the components they are responsible for. On one hand that's good because that's how you parallelize the development effort. But then the people can't view the big picture anymore and this is usually a failure of business analysis, because truth be told most systems are built with a primary purpose (for example the primary purpose of an email platform is to send emails in bulk) and then the "stakeholders" lose sight of that and come up with often useless and often conflicting features that detract the developers from focusing on the primary purpose (e.g. what use has an email platform that's shitty at sending emails). The end result in our team is that a single man knows all the business logic details and dealing with that takes so much of his time that he does not have time for software development at all.
I do not agree with you on studying large systems. Large systems that have to be studied because they are large are in my opinion a failure of design that shouldn't be copied. IMHO, much better is to develop a nose for simplicity and always strive to build simple things, while also pushing back on the amount of work needed by simplifying the business logic.
While I agree with you that the people that can deal with the above are incredibly rare, I'll stick to my initial claim ... people good at it are software developers that (1) are always studying new ways of thinking and learning from others and (2) that try to do things and get burned a lot.
And nr. 2, the experience you've got, is incredibly important. There's no amount of studying that you can do for successfully recognizing and fixing or avoiding concurrency problems (and btw, I'm not talking about multi-threading here, but about the general issue of concurrency that can happen in all sorts of communications). There's no amount of studying you can do that can help you recognize entanglement that shouldn't exist in the architecture. Sure, books help, but books don't fix the superficial attitude that rookies have towards such problems. In order for one to learn, one has to build stuff and suffer from such issues and then improve.
Good news is that if one follows the above advice and gets out of his conform zone, then one can short-circuit the learning process to about 5 years instead of the usual 10.
I mean things like: "Problems X, Y, and Z are actually all caused by the other teams trying to work around the bad build-system. We should fix that first."
Pitch yourself based on what you've done, not who you are. Saying "I'm a software architect" is a red flag for "I'm incompetent and can't actually write code", saying "I built this software system (which you can see at this URL) from the ground up" or "I led a team to build this software system, and here's why it's hard" communicates exactly what you can do.
IMHO, the exposed problem is exactly what's wrong in many development teams. What should happen is this:
1. somebody is feeling too much pain because of the shitty build system, therefore ...
2. that somebody simply setups an alternative and then shows everybody else how great it is compared to the current build system
If this doesn't happen, then the team is fundamentally broken, either because the team has only rookies in it (and rookies tend to be masochists that can take pain) or because the developers simply stopped carrying about the project, for some reason or another (which might be legitimate) and just do the minimal amount of work to cash in their paycheck. If this happens and the build system doesn't get fixed by somebody, then the main problem is not a shitty build system, but a broken team.
The good news is that you don't need an architect label to fix a broken build system, or certifications or other such bullshit. You just have to care enough and invest some effort in fixing it, with the realization that nobody is going to do that for you. Incidentally that's how you get better - sure you might make mistakes along the way, but people that change things are the people that get really good at it.
That isn't actually a position. If you have good devs, the other teams will have communicated that up; if you have good managers, they'll in turn give the teams the freedom to fix the build system (or to work with the devops team to fix it, if there is one).
I think there is such a position. If there are multiple teams, then it's important for someone (a good programmer, but whether they're called "manager" or "lead" or "architect" isn't the point) to have a good understanding of what's going on in all of the teams simultaneously. That person can notice problems that the programmers down in the weeds (even if they're called "senior developer" or "lead") might not be able to see, or might not even think of as being a solvable problem.
Doing this properly for 3-8 teams might well leave that person with little time to contribute meaningfully to any given project, but the bird's-eye view can be very much worth it.
So what you're describing is a 'senior developer' or 'lead developer', who is noticing that the build system is an issue, and reporting it up and suggesting issues.
Whereas I said "If you have good devs, the other teams will have communicated that up".
The only difference I'm seeing is you're positing someone who is aware of developer issues, and 'with little time to contribute meaningfully'. How, if the person isn't developing, is he/she going to be able to tell what the development issues are? He/she can't just ask the developers; if they're aware of it they're not 'down in the weeds', and just communicating it upwards is enough.
I'm pretty sure this issue is best served with a retrospective.
At the OOPLSA 1998 conference, I attended the inaugural meeting of the Intergalactic Society of Software Architectural Awesomeness Rex [1].
Also there was Grady Booch, holding the floor. I was a bit star struck.
When I finally spoke up, I asked "What's software architecture?"
Booch pondered for a moment and then said "Software architecture is what software architects create."
Pop. No longer star struck.
I did eventually find a definition for software architecture in the book "Design Rules: The Power of Modularity". Their definition is (from memory) architecture is the set of visible design decisions for a product.
TL;DR: Don't sweat it. Just write software.
[1] I may have misremembered the name of the organization.
IMHO, and this is really just my personal opinion, the only way to learn how to build a big system is to build one and learn the extent of your ignorance by failing at it the first few times out.
I started a decade ago on my first job on a 20.000 line web app developed with two other guys. Over time that became a 700.000 line system developed by several dozens of people and on track to be a million lines in two years. Between then and now I've learned that I'm very ignorant. I still feel like I'm trying to figure this stuff out and not quite succeeding. :)
As a good second-best choice, try contributing to a large open source project. No books will teach you this stuff, you have to do it to learn it.
If you can work on a green-field project, you'll get a LOT more experience implementing new things that exercise your architect muscles, and you'll be around architects that you can ask why they are making decisions they are. Versus working on an existing project, where you tend to just fix bugs or figure out how to hack in a new feature without breaking what's there. (I don't know which of these camps you're already in, but in general I think it makes a big difference.) (Disclaimer: I am a jr dev, but see a world of difference between what I get to learn and others at my level because of my project.)
One would hope your company would be making these investments in you.
As a developer at [Large well-known software company], after my first year I started being given leadership roles in minor stories, then major stories, then epics that breakdown into major stories.
If the company you work for is not giving you growth opportunities, one might begin to wonder how they picture your future.
Side note: "Software Architect" as a role sounds way too Waterfall to me. People should have varying skills at design, and work together to build the best thing they can. Not have an Architect who claims omniscience and designs the whole project up from.
I'm not sure anyone grows up with computers wanting to make enterprise software. For me it was always games. Lots of games, lots of different mechanics. Maybe I wished for more hours in the day, but I never sat down wishing I could just write more lines of code. But the ball could always bounce more convincingly, the TIE-fighters could always explode in bigger fireballs. Programming was experimenting, exploring.
I didn't end up making games. For the longest time it was billable hours, deadlines, sprints, features, CRUD, lines of code. Always moving faster, always choosing better tools, better methodologies. Arguing about those tools, those methodologies.
Getting older, I've loved the transition from the bums-in-seats, maximum-throughput kind of programming to "oh shit, how can we possibly make it do that?" day-long whiteboard sessions. We always want to move faster, we still argue about how, but we're back to experimenting, exploring.
1000 lines of code a week is bullshit for us, and I don't think this is just about 'senior' developers. My advice to everyone is to find a place where the lines of code don't matter. Go make computers do cool stuff, then think long and hard about how to make it cooler and go do that.
One of the fact that surfaces from the book Just for Fun: The Story of an Accidental Revolutionary is that Linus wrote the code for Linux in ~15 months and it was ~15K LOC. I usually take that as gold standard for productivity of brilliant programmers. Note that as per the book, he almost exclusively spent entire time writing code during these months (he would put down the curtains if it was a rare sunny day outside and skip showers and just about any events so almost all he does is write code).
People seem to be focusing on the number of lines. I think the point is just to recognize you have limits, be realistic on what you can accomplish alone and accept help from others where it is possible.
This is really spot on. The only thing I could add, is that I've found the only way to continue to write code in the capacity he's talking about, is to dedicate a day or days of the week to programming. If you're going to make your 1,000 or so lines meaningful, then the context switch to that mental state is too high when your day is intermixed with distractions.
Sometimes I can put my headphones on at the end of the day and try to get 2 hours in; or work the graveyard shift at home but that's never as good (or healthy really).
I tip my hat to the pure engineering managers who don't code at all. They're more like social engineers than anything, but boy would that be challenging to do 100% of the time.
The best managers I've had were ex-engineers who realized that they couldn't write code any more. One of them explained it like this: "You get your work done by moving lines of code around. I get mine done by moving people to where they're needed, a little like chess." And it was true: He was tuned into the technical issues, and knew what his talent pool was, and was quite good at helping people make decisions about what to work on.
The worst managers I've had have been the ones who thought they could do engineering plus "the people stuff", whereupon they stunk at both. (Well, not the worst -- the absolute worst tried to make all the decisions, too: Code it this way, little robot. Or neck-and-neck, the managers who made no decisions at all and left everyone rudderless until they decided on a product and a deadline; ugh).
Back to coding, that's roughly 50K lines of shipped code a year, which seems pretty high to me. Well, you can definitely do that in a green fields area, like a totally new feature or product. But writing that much code in an existing system is gonna be hard.
The point of the article is just to say "make it count". But since everyone is talking about the number of lines...
This reminds me of the time when this company giving requirement to all their employers to write down how much line of code they have written this week and this senior engineer who was working on an optimization problem wrote -1000. From there on the company removed that policy. (forgot the company, person's name, and the number)
I would have written that as $LOC_DELETED + $LOC_ADDED (i.e. if it was 3000loc and I deleted those and rewrote it in 1000loc, I'd put 4000loc). After all, deleting lines is a net positive change for the project and you need to think a lot about exactly which lines to delete.
I'm spending a lot of time choosing the right backend for an advertising platform. I haven't really written a line of code for a month that I intend to keep. Am I 4000 lines behind then? Then again, maybe I'm doing exactly what the article prescribes: thinking ahead, carefully choosing my libraries, thinking through every use case and then hopefully saving my future maintenance programming a ton of headaches.
People, we can settle this with a line-counting tool. I just used http://gitstats.sourceforge.net/ and it appears I've been authoring over 1000 lines of code a week.
1k loc / week sounds like a lot. As a teenager, I got a tour of a company doing contract work for the government making drones. Their manager said they average 12 lines of "final" code per day per engineer over the course of a project. I was stunned and shocked it's so low, but it has stuck with me ever since. After many years more experience, factoring in bug rates and debugging time and meetings and rewrites and all the other things that eat time, I'm quite convinced that nobody goes as fast as they they think, and in reality all software dev is surprisingly slow, measured over the course of a large project. Granted government / military work is expected to run slower (and more carefully) than most software. But if you're writing code, you're creating bugs, and bugs take time to fix, there's no way around that.
12 lines/day/dev of "final" (tested, debugged, solves a customer problem) sounds about right.
The thing is - most code is not final. You end up writing exploratory code to test out a product, code that's rewritten because requirements change, code to test the actual code, code for projects that go nowhere and end up canceled, code for throwaway migration tools and other important tasks that aren't in the product but are necessary to build the product, code to make your job easier. All of that takes time, but it's not included in the metrics.
When I was at Google I used to joke that the half-life of my code was about a year, meaning that after a year, roughly half the code I'd written had been ripped out and replaced. Casual conversations with many other engineers indicated that their numbers were pretty similar. Over the course of 5.5 year career there, I wrote IIRC about 230,000 lines (there was a tool where you could instantly visualize your code delta across all projects you worked on). With a half life of a year, that's nearly 6 half-lives, meaning less than 1/64th of the code I wrote still exists in the codebase. It works out to about 3 lines of code/day, even though on an instantaneous week-to-week basis I was coding close to 1000 lines/week.
It can vary very widely. I recall somewhere in the work of Capers Jones there was a chart where they tracked lines of debugged code per staff month, and it varied from less than 100 to 5.000 depending on the industry. Which is to say that in some industries moving fast and breaking things is ok, and in some it's not.
How do you know that you are going to write 1000 lines a week? Once you begin to write code you it can happen that the code is more easy to write than to explain and then you can code hundreds of lines in little time, but also it could happen that the code requires very special attention and sophistication, a tough problem, here you can only write a few lines but those are crucial or very important to write for efficiency or memory constraints. What I would suggest is to distribute your time according to the complexity of the modules or parts of the problem, but prior to that you need to have a good understanding of logic and internal structure of the code you are going to develop, and this is also another problem that you must address in your distribution of time.
This is spot on, except I would take it a bit further. You can only accomplish X things in a week. Now, what do you choose to do with your life? If you are writing code ask yourself what is the purpose of that? What is the goal of that app? How are you making the world a better place? Or, as he puts it, isn't there anything else you could be doing that nobody else can, and that would indeed make the world a better place? Could be coding on another project, could be not even coding. But anyway, choose wisely what you do with your life.
