61–70 of 86 posts
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, per…
Earlier quoted context omitted.
I don't think he was suggesting you aspire to that. And both 10 hours and 5 days are probably underestimates of the time he is spending.
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…
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).
Earlier quoted context omitted.
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!
> If I do 750 LOC in a week, that's a good week! I'm so glad I'm not the only one who feels this way.
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…
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.
Earlier quoted context omitted.
So what would be the non-"red-flag" way? 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.
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 al…
Earlier quoted context omitted.
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?
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…
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.
Earlier quoted context omitted.
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…
So what would be the non-"red-flag" way? 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."
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.