131–140 of 212 posts
But: -As a 1-man-band I also do the support, documentation, testing, website, marketing etc. So coding is only part of what I do. -I don't think the article defines what a LOC is. Does it include headers? Does it include auto generated code?
Earlier quoted context omitted.
How is a dependency on AspectJ any more of a liability than the dozens of other external dependencies in your typical application?
It is just as much of a liability, a priori neither more nor less. It needs to be evaluated like any other potential new dependency. Plus, AspectJ is something that you have to be careful with. It injects code at the start or end of methods that can do arbitraty things and the method source code doesn't indicate that this is happening. So it has a great potential for code obfuscation.
In C#, with the various frameworks - including on the API level with ASP.Net - you can use attributes to decorate the classes/methods with your aspects and it’s pretty easy to see what it’s doing.
You get the runtime binding basically by just using dependency injection as you always do.
Does anyone else question the mythical man month? If I accept the basic assumption of the mythical man month then I also have to accept that NYC is a myth - there is no way that a city that size can possibly function. Lets start out with ten people in NYC and they add ten more people .... My own belief is the MMM is an apologists view of how we currently collaborate to develop software and products.
1. Don't know the code base or problem domain. So they'll spend months getting up to speed.
2. Will increase the communication overhead (now each person has to coordinate with up to 9 others, not just 4).
On the small scale of this example, you may see good results. 5 more people isn't a huge amount of communication overhead, and if they're experienced (perhaps even formerly worked on the same or similar project) then you'll see an immediate drop in productivity and then a quick rise back to the new baseline. But will that hold with another 10 people? 20 more beyond that? Each doubling will not continue to halve the time to develop the project, there are limits, and at some point the returns will be negative. The additional people will slow it down. Not just the initial slow-down, but also the new baseline after things settle will be lower than before adding them.
What annoys me most about these metrics is that some days zero lines are written. Anything up to a month without results to show. Where, then, does all this time go? Sometimes it's reading existing code. Sometimes it's learning about a new algorithm by reading blogs and papers. Sometimes it's developing test programs to iron out a bug or test out some new code. There used to be one chap in the office that got all the…
Whenever I spend a week without progress I feel like dying. In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods. How did your manager react to these times ? no remarks ? nagging ? trusting ?
It's also a hell of a lot of fun... which is why it's not really what you get paid for. What you get paid for is the long, tedious slog of the real world: maintaining existing business logic, teasing out user requirements in a domain you don't really understand, dealing with other developers who have different preferences and skill levels, doing variations of the same thing instead of exploring new domains and technologies. You spend a lot of days in meetings that should have been emails.
It's not all drudgery, and it's both more fun and better paid than 99% of the jobs in the world, but it's not picking the wondrous low-hanging fruit that you did in college.
A good construction engineer builds a house using LESS concrete that others.
I'd rather be a good software engineer than a "x10 developer".
What annoys me most about these metrics is that some days zero lines are written. Anything up to a month without results to show. Where, then, does all this time go? Sometimes it's reading existing code. Sometimes it's learning about a new algorithm by reading blogs and papers. Sometimes it's developing test programs to iron out a bug or test out some new code. There used to be one chap in the office that got all the…
At one job, I replaced a 10k LOC class with a 20 line function which probably took me to a net negative loc count for that job.
I did some trivial math. Redis is composed of 100k lines of code, I wrote at least 70k of that in 10 years. I never work more than 5 days per week and I take 1 month of vacations every year, so assuming I work 22 days every month for 11 months: 70000/(22*11*10) = ~29 LOC / day Which is not too far from 10. There are days where I write 300-500 LOC, but I guess that a lot of work went into rewriting stuff and fixing bu…
Has progress on that been fairly continuous with the project growing steadily (almost) nonstop? Or was a big portion of that the groundwork just to get it to a point of being usable in the beginning? With projects I work on, I'll often write a few thousands lines of foundation in a couple weeks, then I'm adding a line here and there as needed. The first 1000 lines are always easy. The next 10 can take days.
If I'm pounding out the same boilerplate code I've written for every greenfield app, I can go at a phenomenal speed. But if I'm put into code I'm not very familiar with, 98% of my effort is understanding the existing code and 2% of it is making that 1-10 LOC change.
Web devs: don't think this applies to you. If you're pushing up 0 lines of code on a day where you had no meetings or interruptions, and you aren't working on something truly novel and near-impossible, you took the day off on the company dime. And everybody you worked with noticed, and if you do it regularly - they are just waiting for everybody to reach their breaking point with you so they can push to get rid of yo…
Anyone else feel sad when you remove a bunch of code? All those man-hours it took to write that code, and now I'm deleting it all. I believe it's called sunk cost fallacy. I often wish I had a time machine so that I could go back in time and say, hey, this will all be deleted a year from now, go with the other solution instead.
I spent a day with just a pencil and paper, considering each detail of the algorithms and came up with several key insights which reduced the whole thing to about 1k lines of code. The reduction was a combination of C macros (which I wouldn't use today, but I'd use higher-order functions to accomplish the same thing now) and just smart generic code (no special handling of an add operator versus a multiplication operator, they were both binary operators; differentiating the output for each case happened in one place at the end).
That was when I found out I liked deleting code. I'll happily reduce a code base by 90% if the result is clearer and easier to maintain or extend.