5 ms·

Strong software tips from 2000 that are 100% valid today

104 points by lucasandrade 6y ago

Shoop 6y ago
Could you change the title to "The Joel Test: 12 Steps to Better Code (2000)"? The guidelines [0] ask that you use the original title and not editorialize. Usually people append the year in parentheses for older posts. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- deleted 6y ago
  [deleted]
- lucasandrade 6y ago
  Yes, sure. Sorry about that. But how can I edit the title? I try to find it here but I couldn't.
smt88 6y ago
Strongly disagree with #11. Writing code in an interview is a great way to tell if someone has social anxiety or feels pressure to get a job. It's a terrible way to tell if they're good at writing software. Do a (paid) take-home test, ask them to review some fake code, or talk to their former coworkers instead. There are lots of shy, anxious people who are fantastic employees and never make it past a stupid whiteboard.
- edoceo 6y ago
  +1 to paid take home. I make sure all companies are ready for this to make sure my candidate pool is respected.
- bkuehl 6y ago
  As much as I want to disagree you have to do somewhat of a coding interview in today's environment. I'm not talking about anything super difficult. Just connecting a database query you've had to write (previous step) to front end code. Having something that simple be take home is asking applicants to put somewhere and pay for someone to do it. Nothing hacker-rank level and you'd be surprised at the number of people that fail. We're not even touching fizz-buzz complexity. Sorry, but you will have to to be able to write a very very basic non-google-facebook level of code in our interview.
- freewilly1040 6y ago
  How do you detect cheating?
  - ehnto 6y ago
    Probably during the interview before even giving them a take home test. If someone is going to cheat on a take home test they will probably expose themselves with even a shallow inquest into their knowledge. That's why you need a trusted competent dev in the interview with you. The take home test gives you a clearer idea of their problem solving skills, but you should probably trust that they know how to write software before getting to that point.
  - smt88 6y ago
    Ask them to explain their reasoning and their code.
- ng55QPSK 6y ago
  Well, if you hire them to _just_ write code, you can do that on take-home (with the risk of hiring a copy-paste-artist). However, if you are looking for a team member that can communicate what she does and how she does it, then you need some interaction.
  - dgellow 6y ago
    When you have a take-home exercise you still have a face-to-face interview where you interact with candidates. And you can talk about the code that the person wrote and dig into it if you think that's relevant. The only difference is that people being interviewed are given more control over their schedule and environment when working on the exercise. IMHO companies who do mostly whiteboard or live coding exercises are passing on some very good candidates who don't perform well in this specific setup but are great collaborators.
- judofyr 6y ago
  If you read the section about point #11 you will see that it's less about whiteboard programming, but rather making sure that they code something during the interview process. Seems that all of your suggestions are in line with this advice. > Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them. Or they are asked trivia questions (“what’s the difference between CreateDialog() and DialogBox()?”) which could be answered by looking at the documentation. You don’t care if they have memorized thousands of trivia about programming, you care if they are able to produce code. Or, even worse, they are asked “AHA!” questions: the kind of questions that seem easy when you know the answer, but if you don’t know the answer, they are impossible. > Please, just stop doing this. Do whatever you want during interviews, but make the candidate write some code.
  - seer 6y ago
    You have to be incredibly lucky, or very experienced in this to ever get an interview coding exercise you look good in. Its incredibly stressful and usually gives the company a very weak signal of what you will they get as a dev. There is soooo much setup in a modern dev process, build tools, compilers, transpilers, code formatting configs, let alone editors, languages and frameworks you are comfortable in, its not even funny. You will be asking a candidate to understand a task completely without any prior knowledge, figure out whats the minimum setup they need to work on it successfully, implement the logic in very few iterations and no coding partners or knowledge repos to help them. Preferably with some testing setup, and to top it off you want them to do it in an hour. As I mentioned it can be done if you are incredibly lucky and know exactly what to do, or have done this before many times in different interviews. And what do you get in return? Can a person work under high stress - e.g. are they ok at working in a shitty environment? If everything this should be a red flag as that person will keep shitty envs around and not go out of his way to fix things. How good are his coding skills? Well not really, you will know that they can do interview tasks - e.g. a small bite sized problems that have easy solutions. Long term planing, refactoring, perseverance, etc. - no signal there. And worst of all, it tells the candidate that your company/team enjoys high stress, small problem, and making each other uncomfortable. Remember an interview is both ways, and you just earned yourself a red flag too. Btw, Adam Grant had some podcast episodes about interviewing last year that were really good and showed some companies that actually solve this in a very nice, humane _and effective_ way.
- BurningFrog 6y ago
  As I remember it, it was Joel who launched the wave of having people actually write code during interviews. I never saw or heard about that before.
  - paxys 6y ago
    Nah, this entire list is just 90s-00s Microsoft (where Joel worked). Whiteboard coding interviews were already standard over there, and I presume they got it from the software companies before them.
- rambojazz 6y ago
  > Do a (paid) take-home test I want every company on Earth to understand this: if you're asking candidate to do a "test" at home, please provide a small compensation/reimbursement. Otherwise it feels like slavery. They can ask 10s of candidates to come up with a solution for a problem for free, and then they use the best one in their projects.
- watwut 6y ago
  After working with guys who in practice could not really code, imo, writing some code without being hired is necessary.
- yread 6y ago
  >Do a (paid) take-home test I would like to do that. How do you put the amount in the company books? It can't be salary as they're not yet signed up, they probably won't be able to give you an invoice or any other document. Or am I just being paranoid and let my accountant handle it?
  - smt88 6y ago
    It's just a simple contract. They don't have to invoice you unless your accountant demands it. Yes, let your accountant handle it :)
- pydry 6y ago
  If you're an excellent coder with social anxiety wouldn't you rather demonstrate your skills in interview rather than pontificate? One of the best interviewees I ever had was super quiet and softly spoken initially but he shone when i gave him a laptop and a task. Moreover, he opened up afterwards. (agree that whiteboards are terrible, but I hate take home tests - 90% of them are ridiculously overscoped. "This 16 hour test should be doable in 3 hours")
- peter_d_sherman 6y ago
  >"Writing code in an interview is a great way to tell if someone has social anxiety or feels pressure to get a job. It's a terrible way to tell if they're good at writing software. Do a (paid) take-home test, ask them to review some fake code, or talk to their former coworkers instead. There are lots of shy, anxious people who are fantastic employees and never make it past a stupid whiteboard." PDS: First of all, that is an absolutely great comment! You nailed it! I couldn't have said it better myself! Second (and this is the more subtle point!): If you're a programmer, and you're looking for a programming job, and you have to go through thousands of job ads; thousands of potential companies, and you need a way to "screen the employer" fast(!) -- then simply ask them what their employee screening procedures are -- and if they tell you that candidates come in and write code on a whiteboard (as opposed to a take-home test!), then you can quickly REMOVE that company from the list of companies you're applying to! Let another candidate waste their time (and possibly a good chunk of their future programming career!) with yet another company that "doesn't get it!". Think of it like this, for any given problem in Math, there are typically long ways to solve the problem, and then (if you know them!), there are algorithmic short-cuts! Well, employer psychology -- is like that, too! Being able to "screen the screener" -- as a result of their screening process(!) -- is a career "algorithmic short-cut"! (I know, how meta, right? <g>) You don't want to spend time with people who don't understand programmers or programming as well as you do(!) -- because if you do, it will drag you and your programming career down!
fergie 6y ago
Joel was one of the very first content marketing geniuses in the Software space. This post was designed to sell FogBugz, which at the time, was a stand alone Windows application that could charitably be described as "not as good as BugZilla". Its interesting to note that other software development methods such as Agile do not mandate the use of things like source control, issue tracking and CI, and therefore make it very possible to set up completely dysfunctional development teams. Refreshingly, the "Schedules" point is in complete opposition to Agile. The Joel Test is an actual thing that you can use to make your software development run more smoothly. There is also a more important point to be made about the Joel Test. While most software development method"ologies" seek to subtly shame, juniorify and undermine developers, Joel's writing seeks to understand, validate and empower them. For this alone he was ahead of his time, and he deserves a lot of credit for the pieces he wrote in the early 00s.
na85 6y ago
Had this article been written in 2019 or so, I could buy it. It seems strange in an article from 2000 to hold up Microsoft as some shining beacon of software engineering excellence. This is, after all, the company that gave us Windows ME, Vista, and Windows 8, to say nothing of the Zune. Or Clippy.
- ahstilde 6y ago
  Do you feel like no good software has come out of Microsoft since Windows 95? That Microsoft has poor engineering practices? They're still 75% of all PCs, have a significant cloud presence, and an even greater gaming presence. Their office suite continues to be the greatest digital productivity tool since the calculator. And they have the largest grasp on developer mind share becuase of Github and VScode.
  - neolog 6y ago
    > Their office suite continues to be the greatest digital productivity tool since the calculator. MS Office is only as successful as it is because of the 1990-2010 Windows monopoly.
  - na85 6y ago
    >Do you feel like no good software has come out of Microsoft since Windows 95? No, but I feel like a lot of really bad software has come out of Microsoft since Windows 95 >They're still 75% of all PCs Purely because of marketing and abusive monopolistic practices in the early days
- sideshowb 6y ago
  Word and excel were both ground breaking when they first came out.
  - tralarpa 6y ago
    In what sense were they groundbreaking? I think Word was a little bit special among DOS programs because it used the mouse. What else?
l0b0 6y ago
It's interesting how these have held up: Do you use source control? Source control is much more common now than in 2000. I worked many years as a software developer before encountering any team which used version control as a matter of course. Before crapping on those developers, consider that version control before DVCSes like Git was slow, broke frequently, took up valuable storage space, and usually required a server which was non-trivial to set up and maintain. Do you make daily builds? Not so relevant now that we can build on every commit for free. Do you have an up-to-date schedule? Not sure what to make of this. Software development is as difficult as ever to estimate. Do you have a spec? Not unless I'm implementing an ISO standard or something. Sounds a lot like waterfall. Do programmers have quiet working conditions? Haha, nope! Dilbertian low walls have completely taken over. Do you use the best tools money can buy? Depends where you work, but most places have onerous acquisition processes. Do you have testers? Only in big projects, where this seems pretty ubiquitous. Do new candidates write code during their interview? Still relevant in lots of companies. Do you do hallway usability testing? Did this one actually ever catch on anywhere except single-product shops? Can you make a build in one step? Do you fix bugs before writing new code? Do you have a bug database? Still super relevant.
- SAI_Peregrinus 6y ago
  Having a spec isn't waterfall at all. A spec is just deciding on what to build before building, it answers the question of "what user visible features are required?" Agile calls specs Design Docs, and generates them from User Stories.
redis_mlc 6y ago
It's a good article to be familar with, but note that a startup with a single engineer using scripting languages doesn't need to do any of the steps.

104 points by lucasandrade 6y ago

Could you change the title to "The Joel Test: 12 Steps to Better Code (2000)"? The guidelines [0] ask that you use the original title and not editorialize. Usually people append the year in parentheses for older posts. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

deleted 6y ago
[deleted]
lucasandrade 6y ago
Yes, sure. Sorry about that. But how can I edit the title? I try to find it here but I couldn't.

smt88 6y ago

Strongly disagree with #11. Writing code in an interview is a great way to tell if someone has social anxiety or feels pressure to get a job. It's a terrible way to tell if they're good at writing software. Do a (paid) take-home test, ask them to review some fake code, or talk to their former coworkers instead. There are lots of shy, anxious people who are fantastic employees and never make it past a stupid whiteboard.

edoceo 6y ago
+1 to paid take home. I make sure all companies are ready for this to make sure my candidate pool is respected.
bkuehl 6y ago
As much as I want to disagree you have to do somewhat of a coding interview in today's environment. I'm not talking about anything super difficult. Just connecting a database query you've had to write (previous step) to front end code. Having something that simple be take home is asking applicants to put somewhere and pay for someone to do it. Nothing hacker-rank level and you'd be surprised at the number of people that fail. We're not even touching fizz-buzz complexity. Sorry, but you will have to to be able to write a very very basic non-google-facebook level of code in our interview.
freewilly1040 6y ago
How do you detect cheating?
- ehnto 6y ago
  Probably during the interview before even giving them a take home test. If someone is going to cheat on a take home test they will probably expose themselves with even a shallow inquest into their knowledge. That's why you need a trusted competent dev in the interview with you. The take home test gives you a clearer idea of their problem solving skills, but you should probably trust that they know how to write software before getting to that point.
- smt88 6y ago
  Ask them to explain their reasoning and their code.
ng55QPSK 6y ago
Well, if you hire them to _just_ write code, you can do that on take-home (with the risk of hiring a copy-paste-artist). However, if you are looking for a team member that can communicate what she does and how she does it, then you need some interaction.
- dgellow 6y ago
  When you have a take-home exercise you still have a face-to-face interview where you interact with candidates. And you can talk about the code that the person wrote and dig into it if you think that's relevant. The only difference is that people being interviewed are given more control over their schedule and environment when working on the exercise. IMHO companies who do mostly whiteboard or live coding exercises are passing on some very good candidates who don't perform well in this specific setup but are great collaborators.
judofyr 6y ago
If you read the section about point #11 you will see that it's less about whiteboard programming, but rather making sure that they code something during the interview process. Seems that all of your suggestions are in line with this advice. > Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them. Or they are asked trivia questions (“what’s the difference between CreateDialog() and DialogBox()?”) which could be answered by looking at the documentation. You don’t care if they have memorized thousands of trivia about programming, you care if they are able to produce code. Or, even worse, they are asked “AHA!” questions: the kind of questions that seem easy when you know the answer, but if you don’t know the answer, they are impossible. > Please, just stop doing this. Do whatever you want during interviews, but make the candidate write some code.
- seer 6y ago
  You have to be incredibly lucky, or very experienced in this to ever get an interview coding exercise you look good in. Its incredibly stressful and usually gives the company a very weak signal of what you will they get as a dev. There is soooo much setup in a modern dev process, build tools, compilers, transpilers, code formatting configs, let alone editors, languages and frameworks you are comfortable in, its not even funny. You will be asking a candidate to understand a task completely without any prior knowledge, figure out whats the minimum setup they need to work on it successfully, implement the logic in very few iterations and no coding partners or knowledge repos to help them. Preferably with some testing setup, and to top it off you want them to do it in an hour. As I mentioned it can be done if you are incredibly lucky and know exactly what to do, or have done this before many times in different interviews. And what do you get in return? Can a person work under high stress - e.g. are they ok at working in a shitty environment? If everything this should be a red flag as that person will keep shitty envs around and not go out of his way to fix things. How good are his coding skills? Well not really, you will know that they can do interview tasks - e.g. a small bite sized problems that have easy solutions. Long term planing, refactoring, perseverance, etc. - no signal there. And worst of all, it tells the candidate that your company/team enjoys high stress, small problem, and making each other uncomfortable. Remember an interview is both ways, and you just earned yourself a red flag too. Btw, Adam Grant had some podcast episodes about interviewing last year that were really good and showed some companies that actually solve this in a very nice, humane _and effective_ way.
BurningFrog 6y ago
As I remember it, it was Joel who launched the wave of having people actually write code during interviews. I never saw or heard about that before.
- paxys 6y ago
  Nah, this entire list is just 90s-00s Microsoft (where Joel worked). Whiteboard coding interviews were already standard over there, and I presume they got it from the software companies before them.
rambojazz 6y ago
> Do a (paid) take-home test I want every company on Earth to understand this: if you're asking candidate to do a "test" at home, please provide a small compensation/reimbursement. Otherwise it feels like slavery. They can ask 10s of candidates to come up with a solution for a problem for free, and then they use the best one in their projects.
watwut 6y ago
After working with guys who in practice could not really code, imo, writing some code without being hired is necessary.
yread 6y ago
>Do a (paid) take-home test I would like to do that. How do you put the amount in the company books? It can't be salary as they're not yet signed up, they probably won't be able to give you an invoice or any other document. Or am I just being paranoid and let my accountant handle it?
- smt88 6y ago
  It's just a simple contract. They don't have to invoice you unless your accountant demands it. Yes, let your accountant handle it :)
pydry 6y ago
If you're an excellent coder with social anxiety wouldn't you rather demonstrate your skills in interview rather than pontificate? One of the best interviewees I ever had was super quiet and softly spoken initially but he shone when i gave him a laptop and a task. Moreover, he opened up afterwards. (agree that whiteboards are terrible, but I hate take home tests - 90% of them are ridiculously overscoped. "This 16 hour test should be doable in 3 hours")
peter_d_sherman 6y ago
>"Writing code in an interview is a great way to tell if someone has social anxiety or feels pressure to get a job. It's a terrible way to tell if they're good at writing software. Do a (paid) take-home test, ask them to review some fake code, or talk to their former coworkers instead. There are lots of shy, anxious people who are fantastic employees and never make it past a stupid whiteboard." PDS: First of all, that is an absolutely great comment! You nailed it! I couldn't have said it better myself! Second (and this is the more subtle point!): If you're a programmer, and you're looking for a programming job, and you have to go through thousands of job ads; thousands of potential companies, and you need a way to "screen the employer" fast(!) -- then simply ask them what their employee screening procedures are -- and if they tell you that candidates come in and write code on a whiteboard (as opposed to a take-home test!), then you can quickly REMOVE that company from the list of companies you're applying to! Let another candidate waste their time (and possibly a good chunk of their future programming career!) with yet another company that "doesn't get it!". Think of it like this, for any given problem in Math, there are typically long ways to solve the problem, and then (if you know them!), there are algorithmic short-cuts! Well, employer psychology -- is like that, too! Being able to "screen the screener" -- as a result of their screening process(!) -- is a career "algorithmic short-cut"! (I know, how meta, right? <g>) You don't want to spend time with people who don't understand programmers or programming as well as you do(!) -- because if you do, it will drag you and your programming career down!

fergie 6y ago

Joel was one of the very first content marketing geniuses in the Software space. This post was designed to sell FogBugz, which at the time, was a stand alone Windows application that could charitably be described as "not as good as BugZilla". Its interesting to note that other software development methods such as Agile do not mandate the use of things like source control, issue tracking and CI, and therefore make it very possible to set up completely dysfunctional development teams. Refreshingly, the "Schedules" point is in complete opposition to Agile. The Joel Test is an actual thing that you can use to make your software development run more smoothly. There is also a more important point to be made about the Joel Test. While most software development method"ologies" seek to subtly shame, juniorify and undermine developers, Joel's writing seeks to understand, validate and empower them. For this alone he was ahead of his time, and he deserves a lot of credit for the pieces he wrote in the early 00s.

na85 6y ago

Had this article been written in 2019 or so, I could buy it. It seems strange in an article from 2000 to hold up Microsoft as some shining beacon of software engineering excellence. This is, after all, the company that gave us Windows ME, Vista, and Windows 8, to say nothing of the Zune. Or Clippy.

ahstilde 6y ago
Do you feel like no good software has come out of Microsoft since Windows 95? That Microsoft has poor engineering practices? They're still 75% of all PCs, have a significant cloud presence, and an even greater gaming presence. Their office suite continues to be the greatest digital productivity tool since the calculator. And they have the largest grasp on developer mind share becuase of Github and VScode.
- neolog 6y ago
  > Their office suite continues to be the greatest digital productivity tool since the calculator. MS Office is only as successful as it is because of the 1990-2010 Windows monopoly.
- na85 6y ago
  >Do you feel like no good software has come out of Microsoft since Windows 95? No, but I feel like a lot of really bad software has come out of Microsoft since Windows 95 >They're still 75% of all PCs Purely because of marketing and abusive monopolistic practices in the early days
sideshowb 6y ago
Word and excel were both ground breaking when they first came out.
- tralarpa 6y ago
  In what sense were they groundbreaking? I think Word was a little bit special among DOS programs because it used the mouse. What else?

l0b0 6y ago

It's interesting how these have held up: Do you use source control? Source control is much more common now than in 2000. I worked many years as a software developer before encountering any team which used version control as a matter of course. Before crapping on those developers, consider that version control before DVCSes like Git was slow, broke frequently, took up valuable storage space, and usually required a server which was non-trivial to set up and maintain. Do you make daily builds? Not so relevant now that we can build on every commit for free. Do you have an up-to-date schedule? Not sure what to make of this. Software development is as difficult as ever to estimate. Do you have a spec? Not unless I'm implementing an ISO standard or something. Sounds a lot like waterfall. Do programmers have quiet working conditions? Haha, nope! Dilbertian low walls have completely taken over. Do you use the best tools money can buy? Depends where you work, but most places have onerous acquisition processes. Do you have testers? Only in big projects, where this seems pretty ubiquitous. Do new candidates write code during their interview? Still relevant in lots of companies. Do you do hallway usability testing? Did this one actually ever catch on anywhere except single-product shops? Can you make a build in one step? Do you fix bugs before writing new code? Do you have a bug database? Still super relevant.

SAI_Peregrinus 6y ago
Having a spec isn't waterfall at all. A spec is just deciding on what to build before building, it answers the question of "what user visible features are required?" Agile calls specs Design Docs, and generates them from User Stories.

redis_mlc 6y ago

It's a good article to be familar with, but note that a startup with a single engineer using scripting languages doesn't need to do any of the steps.