This is Thomas's Typepad Profile.
Join Typepad and start following Thomas's activity
Join Now!
Already a member? Sign In
Recent Activity
@Jaap Van der Velde: "(Good) documentation is a description of what the software designer/programmer wanted to write" Not exactly true. Documentation is a description of what the developer wanted to write *when they wrote the documentation*. However, the probability that the documentation will skew from revised intentions approaches 1 as the code becomes more mature. The code is the only truth about what a given routine actually does as opposed to what the documentation claims it does. It is the (current) users that dictate what it ought to be doing. TBH, what is being discussed here are black boxes. If you drop a component into your solution and it works as expected, then the source of the component isn't necessary. The problem comes when the black box doesn't do what you expect and you have to figure out why. If the documentation helps to get over your problem, then great but at the end of the day, what really will help get past the problem is the source of the black box. That will truly tell you how the component is actually working.
Toggle Commented May 2, 2012 on Learn to Read the Source, Luke at Coding Horror
I don't get the fascination with Chrome especially since it lacks sidebars and a true NoScript plugin. The load time argument to me is silly. I load FF once and keep it open until I log out of the machine. Frankly, there are times when the uber-minimalist approach is annoying. I like that in FF4 and IE9 you can restore the menu bars or hide them as preferred. The auto-updating sounds great when A: it works, B: nothing in the new version is undesirable and C: nothing in the new version breaks functionality. When the day comes that any of those are false, I think people will be less thrilled with the auto-updating.
Toggle Commented May 29, 2011 on The Infinite Version at Coding Horror
First, I've been on both sides of the interview table. Clever math questions, "thought" provoking questions like how many eggs fit in an 747, clever questions about string reversals, linked lists v. arrays are all pointless. I've used 'em and had them used on me and in the end they had little bearing on the interviewee's impression of me or my impression of the candidate when I was the interviewer. I've run into plenty of "smart math guy" or "good puzzle solver guy" that couldn't build solutions to save their life. In my 30+ years coding, the number of times I've actually leveraged my math background or some CS trick like bubble sorts is tiny. I work with some people now that couldn't solve a simple math puzzle to save their life but regularly churn out clean, usable, maintainable solutions. I would much rather have "maintainable solution guy" than "clever math guy". When I interview people, I look for a couple of things: 1. "Are they a tinker" questions. These include whether they have their own systems at home, what they are using, why did they pick what they did etc. If a candidate does not have their own setup at home that disqualifies them on the spot. If they aren't problem solving at home, they won't at work. 2. "Are they a resume leech" questions. A resume leech is someone that puts on their resume a project, on which they actually worked, but were a minor player. So they describe in great detail this complicated system that was mostly built by someone else and claim it for their own. To weed these folks out, I ask them in detail about the project and how they got specs, what were some of the pitfalls, who were the stakeholders, and so on. 3. "Are they honest" questions. The resume leech questions are part of this, but the single worst thing to me is to find someone that is dishonest. The simplest means to determine this is to ask them a question to which they are very unlikely to know the answer. I want them to tell me they don't know. This isn't a clever question. This is something tangible. For DBAs I used to ask them to tell me the difference between a unique constraint and a unique index. Most candidates will try to BS me. BS me once during the interview and that's the end of the interview which is why I usually ask this type of question early. 4. Lastly, the only way to truly know if a developer knows what they are doing is to actually have them do something. I typically have some minor projects handy to dole out to interviewees to see if they can do it. I remember one company to whom I contracted, had a simple app they had the candidate build on the premises. Once piece of the spec was intentionally missing. They used that to see if the candidate would spin their wheels or actually ask someone. I can't say my system is perfect because it definitely is not. But I has helped me trim the interview times down and get good people or identify bad people quickly.
Toggle Commented Mar 6, 2010 on The Non-Programming Programmer at Coding Horror
Thomas is now following The Typepad Team
Mar 5, 2010