Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going Fast Slowly

varnish-cache.org

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Going Fast Slowly

#61

Post by aidenn0 »

p1necone wrote: post #59
josephg wrote: post #47

Earlier quoted context omitted.

I've been doing tech interviews professionally for a large tech interview platform that you would have heard of. We have a timed coding challenge, but code quality is something we explicitly look for. Making slow but steady process with good testing is a great signal for us too, even if they don't get very far through our challenge within the allocated time. That said, occasionally we have people who work very quickl…

I hope it's communicated that they're not expected to finish. If I was given a coding challenge with a time limit I would assume I was expected to finish inside the time limit and make any sacrifices that needed to be made to achieve that - including ignoring testing and hoping I just don't make too many mistakes.

Assuming GP is talking about what I think he is, then yes they tell you ahead of time.

Re: Going Fast Slowly

#62

Post by kube-system »

quickthrower2 wrote: post #49
haberman wrote: post #45

Earlier quoted context omitted.

There's also this from Bill Gates: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

/** I'd agree that counting the occurrences of 0x0a can be misleading */

Of course that would be misleading! ...because Bill Gates would count “0x0d 0x0a” instead. :)

Re: Going Fast Slowly

#63

Post by bch »

pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f 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. http://plasmasturm.org/log/linesspent/

Or Bill Gates -

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

Re: Going Fast Slowly

#64

Post by stkdump »

bt848 wrote: post #20

10 LOC/h is spectacularly good over a long time period. Congratulations, from a varnish user. I recently tried to set expectations in a coding interview that was scheduled for 3 hours. I told them that was enough time to read the spec, develop a simple test case, and begin or possibly complete an implementation of part of the spec. I also told them that I wasn't interested in a shop that hired people based on their a…

Most coding interview challenges I came along are of limited complexity. I think it is important to clarify that reading, discussing the spec, writing tests a priori is something you would do in a real world coding task, but interviewers are usually more interested in the ability to discuss different approaches to solve them with their expected pros/cons, explain why some approaches won't work, prototype one out with some clean code and explain your thinking while writing the code. An experienced developer usually won't make a lot of mistakes for simple problems that require unit tests to see. If they do, the interviewer will make them aware and play the role of the testing, just to see how the candidate would react and solve the problem.

Re: Going Fast Slowly

#65

Post by emmelaich »

pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f 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. http://plasmasturm.org/log/linesspent/

all code is debt

all code is investment

only time will tell

Re: Going Fast Slowly

#66

Post by jacquesm »

draw_down wrote: post #51
jacquesm wrote: post #37

Earlier quoted context omitted.

The hell it does. Dijkstra's words are as important, if not even more important than when they were first written. The whole problem is that we keep re-inventing the wheel and all associated problems over and over again. We never put the lessons learned the hard way to practice in the long run. New generation -> rinse, repeat.

I get that you have axes to grind, but that all doesn’t actually have anything to do with what I was talking about, which is essentially that nobody thinks “lots of lines of code” is a good thing anymore. I work in a startup full of twentysomethings. None of them have read “Mythical Man Month” but they all know the bit about how adding engineers to a late project makes it later. It takes time, but these things find t…

Consider that your personal experience is no match for what we have encountered in about 140 tech reviews of companies in various industries. I'm super happy to hear that you and your crew are clued in and doing well, and that this is all 'old hat' to you.

Even so, there are lots of other companies out there, some older, some newer, both large and small in regulated industries, e-commerce and so on who could very well use some of the common sense that pervades you and your team.

It's definitely not 1988 anymore. Contrary to popular wisdom the programmers from back then usually were clued in, rather than that they went to javascript bootcamp and started churning out reams of low quality code. Plenty of the software from back then is still around today. The Mythical Man Month writes about a team of reasonably competent professionals and the pitfalls they encounter, not about a bunch of clueless newbies.

That adding engineers to a late project makes it later is now an established fact, you would hope. And yet, not a month goes by without encountering exactly that proposition.

So yes, maybe we do need that periodical reminder that 'goto' is bad and that we shouldn't use it too, fortunately the number of languages that support that construct is dwindling, and in those cases where it is used it is hidden quite well without the nasty side effects that an uncontrolled jump into them middle of a bunch of conditionals could cause.

Re: Going Fast Slowly

#67

Post by 314 »

While it is true that SLOC is not a good measure, this does not mean that no good measure uses SLOC. Much of the variance comes a lack of information about coding style and algorithmic approach. But it's not the 90s anymore. In the presence of a style guide and code reviews to ensure that the local style is being followed properly SLOC counts do become locally comparable as a reasonable measure. I'd still use the churn rate (lines added + line removed) as a rate of productivity though, over just lines added.

Re: Going Fast Slowly

#68

Post by openfuture »

jamesb93 wrote: post #33
thaumaturgy wrote: post #28

Earlier quoted context omitted.

Software-as-art has lost a lot of ground to software-as-business, and in software-as-business, somewhere up the chain there is a management-level individual who isn't really sure how to measure either progress or code quality. There are myriad tools designed for these people though, and they all chose the simplest (and wrong) solutions to the problem: progress is SLOC added and bug reports clsoed per day. The height…

Do you have any suggested reading around software as art vs business? You pretty much began to articulate the things I've been thinking about lately.

Masters of Doom about John Carmack and John Romero is in big part about the shareware days and the art vs business of programming.

Re: Going Fast Slowly

#69

Post by 2rsf »

jchook wrote: post #3

“Slow is smooth, and smooth is fast” Old military saying that I repeat often because I have relearned so many times that shortcuts cause more work (read: problems and rigidity) in the long run. Choose one: get it done right, or get it done right now.

unfortunately this does not hold up to reality, in many cases building the right stuff from the beginning is either too long, and you will be late to the market, or simply impossible since you don't have enough information from customers using the product.

Among the many wrong reasons to the Agile way of working being able to change and adapt to reality is a valid and important one.

I don't know which army are you referring to, but my army reverted to heavy bombing if smooth haven't worked.

Re: Going Fast Slowly

#70

Post by icebraining »

thaumaturgy wrote: post #28
lucideer wrote: post #9

Earlier quoted context omitted.

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

Software-as-art has lost a lot of ground to software-as-business, and in software-as-business, somewhere up the chain there is a management-level individual who isn't really sure how to measure either progress or code quality. There are myriad tools designed for these people though, and they all chose the simplest (and wrong) solutions to the problem: progress is SLOC added and bug reports clsoed per day. The height…

> There are myriad tools designed for these people though, and they all chose the simplest (and wrong) solutions to the problem: progress is SLOC added and bug reports clsoed per day.

Is the SLOC counting still a thing nowadays, though? I've worked at companies ranging from 4-person startups to an old worldwide behemoth (all in the EU, though) and nobody even tracked SLOC, let alone evaluate developers on that; all the dumb metrics came from the issue tracker. Though I have the impression your real evaluation is based on how well you work with others, assuming you clear a low technical competence bar.

Post reply on HN