rw140's comments

I think that there's a tradeoff between software engineers being able to work well on this specific problem, and knowing which problem is a good problem to work on. The first benefits from being isolated; the second from having the rest of the team nearby.

To me it makes it HN feel that little bit less welcoming. I may be being over-sensitive, but it makes me feel like I'm eavesdropping on a conversation I wasn't supposed to be part of.

Although, heck, maybe he talks about masturbating in front of girls the whole time.

See also http://news.ycombinator.com/item?id=1717023

Generally I don't get asked for an estimate until after I've done the design, so these numbers are code, unit test and very basic test on real hardware only. These are the rules I use:

- If I think I understand everything it involves, then I take my estimate for all the bits, add them up and multiply by 4.

- If I think I understand everything it involves, have done something similar before, and gone through my list of things to do a couple of times looking for stuff I've forgotten, I can multiply it by 2 instead. If I'm unsure how long something will take I am never allowed to round down.

- If I find myself sizing something with the word 'just' in the sentence, I'm missing something big. (e.g. Then it's just a matter of recreating the error condition and making sure my error gets triggered correctly.)

- If I'm not almost finished (i.e. functionality working with some hacks, unit test passes) by halfway through the time then I'm going to miss my deadline.

- I am still mystified as to where that other half of the time goes (I have a proper 90% rule going on), but some of it is getting my code in a shape where I'm happy about checking it in - dealing with comments so they mean things to people other than me, removing ugly bits of code, checking with co-workers in places where I wasn't sure I'd made the right decision. My maximum speed on this is about 500 lines a day. Some more time is then spent getting things back working again, because I'll have broken things in the process. And I need at least a day to get a sandbox build behaving properly, and willing to run on my hardware.

edit: formatting

Orange buttons than red buttons, but an interesting case study nonetheless.

I wonder whether red buttons would have been less effective, given the association with warning / stop (at least in some cultures).

They're questions about the people you'll be working with and for - can you learn from them, can you work with them, can you trust them, is the team focussed on 'creating value' (instead of just marking time or playing politics), are they going to take an interest in your growth and development?

My current rule of thumb is that if I don't think that I'm 90% done when I'm only 50% of the way through my schedule I'm going to miss my deadline.

My suspicion about the cause of this is that I'm conflating 'easy' with 'doesn't take long'. I think there may be some other factors to do with not wanting to admit I'll break stuff when tidying code (so not allowing time to fix it) and somehow assuming that all the little niggles that only take a couple of hours to fix will all be fixed in the same couple of hours.

Article dates from 2007.

Well, 'talk to your customers' is a little different from 'listen to your customers and make sure you understand exactly what problem your product/service solves for them'. And I think the only difference between evolution (as you've described it) and validation is that seeing how people use what you build, and getting qualitative data on those users is emphasised, rather than something that just happens over time.

At a minor level, that could be making sure that the next feature you implement is the one that will make your software much more usable from their point of view, rather than the shiniest or most technically interesting to implement. (e.g. it doesn't matter if your mousetrap automatically telling your computer when it's caught something, if their local mice just aren't interested in $bait_that_works_best_in_bobs_house )

On the larger scale, if your customers are using your product to solve a problem you didn't expect, you can't optimise your product so it sells even better. If the largest user of your mousetrap is the gremlin-catcher's guild, then perhaps you need to look at building more gremlin-specific features, and changing your marketing a little.

And, of course, the simplest metric for validation is that if they ain't buying it then it ain't doing what they want enough for them to pay for it.

Disclaimer: I have never run a startup, let alone used these principles. They just seem to make sense to me.

Is this article somehow getting past the duplicates filter? I'm sure I've seen it here before, and Google turned up http://news.ycombinator.com/item?id=1164968 and http://news.ycombinator.com/item?id=1130197 (not sure if either of these were actually the version I read).

I'd particularly recommend being part of one of the smaller sports clubs - as well as being part of a different social group from those on your course (it's really useful to have a group of friends who aren't all exactly your age and who won't be massively stressed at exactly the same time) you get to learn new skills and even get some exercise.

From a more clinical point of view, it's also a good place to get proof of 'can function as part of a team' - which is another thing employers care about.

Depends on your definition of fun, but I've used text books to give me practice exercises, instead of having to invent problems myself. (It's also a good way to learn a language's way of working, rather than learning how to implement your old thought patterns in a new language.)

Something like SICP has problems that are fairly interesting from a mathematical perspective as well as a coding one. I don't know if there's the equivalent for Python, but it might be worth checking.

I'd take the view that the emphasis has shifted from 'can we do this? / is it possible' to 'how shall we do this? / what will make our users happiest'. Both of these are great aims, but the former is probably more fun. There will still be edges where the emphasis is still on 'is it possible' but as the technology matures, you'll probably have to seek them out, rather than be there automatically.

I've not tried any of them myself, but the list in the article from http://news.ycombinator.com/item?id=1134301 seemed quite sensible.

It might depend on your personality - although you can be sure that you can be a good programmer 100% of the time, I know I occasionally make decisions that, in hindsight, are significantly stupid. Currently I can sanity-check things with my co-workers (or at least those of them that can spot signs of my stupidity) - if I were a sole programmer, that resource would not be available, so I'd either spend much more time checking my work, or end up wasting more time doing things the wrong way. Possibly even both.

Unfortunately astrological signs didn't give me any 'opposites' I can compare myself with. Having read through the descriptions of various character types associated with various astrological signs, I cannot say I identify with one any more than another.

MB-types give me a set of sliding scales. I show up as strongly I and strongly N, which allows me to compare myself with ES types - I recognise very little of myself in ES types, and a lot more of myself in IN types, which means I'm biased towards the assumption that there is at least some basis to it.

I can also make predictions about what types my friends are, and (before telling them my guess) ask them what type they are. Currently these predictions seem to be matching up pretty well, although a little fuzzy on the P/J axis.

Round here we use a variety of techniques:

* As everyone else has mentioned: headphones.

* Work at home when you're doing a particularly complex piece of work.

* Stagger working hours so that there are times when not all employees overlap - start time is anything from (approximately) 8am to 10am.

* Set instant messenger statuses to 'away' or 'in a meeting' for critical work. (This one only works for people not within line-of-sight.

* Have team leads (approx 1 for every 6 people) who can answer more general questions and so act as a buffer between programmers and people who might need to interrupt them.

* Provide people with the ways to find answers rather than the answers themselves (This has the dual purpose of making it less convenient to ask you than to look stuff up, and teaching people to be more independent.)

* Have times when you are more clearly interruptible - this groups the questioning / passing the time of day, so you can get a longer uninterrupted stretch later.

edit: formatting

I was interested in the assertion that most books aren't fashion items, so it doesn't make sense for the price to go down over time. I'd have thought that this effect would still be there, even if it's less pronounced than on blockbusters - publicity will be timed to coincide with the launch, and I'd imagine most people waiting for the next instalment will want it sooner rather than later.

"my experience is that people do that with "old school" computers too. Only then it does break their computers."

So basically we're looking at a product that will function well instead of breaking when a typical user uses it in a typical fashion? Surely that's a good thing?

Some of it might be a matter of experience.

It's just taken me 30 days to add some new CLI functionality to a piece of code (my first ever time working with this bit of the code stack - I'm not familiar with the underlying code, the debug tools, the various ways the build can fail). I know that the standard time for an experienced CLI developer to implement the equivalent extension of functionality on this section of the code is 3 days.

My second piece of CLI functionality is on track for 15 days... so by the time that's finished I will only be 5 times worse. :)