You only get 1,000 lines of code a week
onebigfluke.com
onebigfluke.com
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.
e.g. Rails core (system) vs people who use Rails (applications).
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.
And both 10 hours and 5 days are probably underestimates of the time he is spending.
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
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).
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.
I'm a fast typist, and I can't type that fast.
[1] 75 hrs/week * 4 weeks * 3600 sec/hr / 'over' 150,000 lines = 'under' 7.2 sec/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'm so glad I'm not the only one who feels this way.
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 don't think I've ever written more than a few hundred LOC in a week.
Sometimes I hack away 100s of lines a day and sometimes I search for problems for days without writing a single (persistent) line of code.
I think the longest span I went was about 3 weeks till I tracked down a bug in a legacy system and wrote about 4 lines to fix it :D
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.
However, most code is rewritten/refactored many times. So only little of what you write in any week will be the _final code_.
A line of Ruby is worth a <INSERT-RAGE-HERE> lines of Java.
~Dijkstra
https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
I'm reminded of the "-2000 lines of code" story: http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
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.
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 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.
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.
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.
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 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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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)
Very likely Apple.
See for yourself at http://github.com/EGreg/Q
300k lines of code over about 3-4 years
Seems reasonable for real software (as opposed to 'copy-paste, who cares if the user has to hit F5 once a day?' code) to me.
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 should be the 'thought' that counts.