How I learned to program | Hacker News Reader

How I learned to program

danluu.com

174 pointsswyx44 comments

> The Joel Test is now considered to be obsolete because it awards points for things like "Do you have testers?", which aren't considered best practices by most devs today.

Is having dedicated testers really not a best practice? I mean if I compare my experience between projects where we had testers and projects where we didn't, I felt we had better results when we did, if only because it'd free up lot of time from the developpers, who don't have to run a lot of tests and the testers usually think of edge case that we overlook. One downside of having testers is that it kinda slowed down the process of test automation, but in that particular case, it's not the only cause.

> Is having dedicated testers really not a best practice?

It is still a best practice. A lot of companies are doing crazy things that Joel would not agree with -- for example, adopting open office layouts, dropping their QA department, and constantly rewriting code. Joel is not wrong that these are bad ideas, regardless of whether they are widely used or not.

Rather, I think it's just more evidence of the growing power of monopolies, that firms can adopt inefficient practices because they are so entrenched.

Well, that's convenient. Whenever companies do things I disagree with and succeed, it's evidence they must be monopolies!

Indeed that could be evidence depending on the strength of the beliefs underlying the disagreement. Imagine the parent commenter simply sought out expert consensus and that the consensus was unmistakable; surely you’d agree that if some practice “disagreed”, there’s a higher than average chance something unusual is going on, like monopoly; that’s “evidence”.

Only if the "experts" had strong objective evidence for their consensus in the first place, which is usually not the case. If you have objective evidence you don't need experts.

It isn't really evidence of much. One of the most reliable consensus points of experts is "you need to hire lots of people in my field of speciality and they should be treated really well and their work should be regarded as important!". Not an iron-clad law, but a reliable trend.

I'll single out "dropping their QA department" as an example of exactly the sort of situation where expert consensus would quite possibly sit in opposition to a good business outcome.

If someone wants to argue there is a monopoly, the evidence should be of a "competition is illegal or physically impossible" nature. Not disagreeing with business practices. Business practices are important but not the be all and end all of success.

Testers absolutely still have a role to play, but not as manual test execution robots. That stuff can be automated. I find value in skilled testers in exploratory testing, sanity checks on if product flows make sense and helping define scope on what things are best covered by automation

At work we usually manual tests, and we try to have them done by someone that didn't develop this specific feature. I feel like some testers would help here, and would also help reduce the need for developers that they can't recruit fast enough. They transitionned a decade ago from waterfall to agile, and removed the testing team. Since what we're doing is basically waterfall on a 2 week cycle, I think dedicated testers would make sense. We have dedicated documentation and localization people. I feel like we're underestimate the work of a good tester by thinking it can easily be done by a developer, and that we're undervaluing the time of the developers.

Having dedicated testers is great, but not the kind Joel is talking about. He's talking about low-paid manual laborers whose work has mostly been automated, not accomplished programmers whose work is considered just as valuable as that of writing the production code they're responsible for testing, and who spend a lot of their time on automating the test process. Joel's argument is specifically that testers are cheaper than programmers, so it's silly to have programmers test their own code instead of having testers do it. Contrast Dan Luu's internship work as a tester:

> Most of them were only slightly less manual than "testing" a phone by mashing buttons, but I did one not-totally-uninteresting task, which was to verify that a flash chip's controller behaved correctly. Unlike my other tasks, this was amenable to automation and I was able to write a Perl script to do the testing for me. ... they had me do verification on the logic they were writing. They had a relatively new tool called SixthSense, which you can think of as a souped-up quickcheck. The obvious skill I learned was how to write tests using a fancy testing framework, but the meta-thing I learned which has been even more useful is the fact that writing a test-case generator and a checker is often much more productive than the manual test-case writing that passes for automated testing in most places

It also depends on what you're developing. In games, in particular, dedicated testers/QA are very much part of the norm and best practices in a different way compared to web apps.

That is an excellent point.

Joel is specifically referring to the kind of testers that Microsoft had at the time the Joel Test was written (Aug 2000).

At that time, for Windows and Office, Microsoft had testers who would write their own test plans (and then execute the tests themselves).

This is not the low-paid manual labor you're thinking of where a test manager writes a test plan and then delegates it to folks who are expected to just follow instructions.

The "manual labor" style of testing was/is typical of game dev companies, where it's easy to trick inexperienced kids into working for very cheap or even free, just to have early access to upcoming games and the (mostly illusory) opportunity to land a "real job" in the game industry.

In some companies these game testers are treated as second class citizens in every way imaginable.

If I remember correctly, JS very much cherished skilled testers and emphasized that they ought to be experienced, that they’re doing a very hard job.

I personally never worked with dedicated testers, but I appreciate both lower level automated tests for critical code, and higher level acceptance, even manual tests by domain experts. Some of the best feedback I got was from people who can’t program but are much closer to the real world problems.

Thank you for adding that context! I didn't know that. In https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... Joel lays out his reasoning:

> If your team doesn’t have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you’re wasting money by having $100/hour programmers do work that can be done by $30/hour testers. Skimping on testers is such an outrageous false economy that I’m simply blown away that more people don’t recognize it.

I still think jobs for people to "write their own plans and then execute the tests themselves" have mostly been automated out of existence, and they were still low-paid in Joel's mind.

> I still think jobs for people to "write their own plans and then execute the tests themselves" have mostly been automated out of existence,

Where I work, it's complicated to automate a lot of things, mostly because of the various installation configuration and how testing has to rely on external hardware like HSM and smartcards. And so the QA write the test plans and execute them, with automation testing non-regression on the most current use cases

> and they were still low-paid in Joel's mind.

Though I think the QA people at my current job at less paid than the equivalent on the dev side.

Hopefully they are paid more than the 30 cents on the dollar Joel is citing!

In my experience xp with pair programming and TDD turned out to be much faster than relying on testers. Relying on QA (besides certain, rare, edge cases) feels like a bottleneck now.

I agree with you on the bottleneck. Our QA is split into automation coders/testers and manual testers, the former of whom never have enough people for complete coverage and the latter of whom are not very technical and the feature developers often have to walk them through exactly how to test the features, which takes even more time away from core feature building.

Not having testers is cheap though.. At first at least..

We have dedicated QAs and QEs, but they are not there to write tests.

It's possible that's what he's driving at as I think the Joel test saw testers as an integrated part of the software delivery pipeline. Nowadays, in big tech, they are more there to drive high level tooling and testing culture - engineers are responsible for writing tests. At least that's my experience.

This is fascinating because apparently the author graduated HS one year after me. There were places that my experience matched almost exactly (e.g. nobody I knew used source control in school) and some that were different.

I was a bit jealous to see his first hire was at Centaur. There are very few teams that make microprocessors that aren't full of great people to work with.

Actually on that note, can anyone in hardware comment about whether or not hardware people tend to all be awesome, or is it just the hardware people that they let out of their caves to work with embedded software developers?

I always have trouble with reading Dan's blog, so I added some custom CSS here https://twitter.com/swyx/status/1449472712720601088 with some explainers

I don't know if Chrome has anything similar, but Firefox reader view is awesome for formatting an article and making it easier to read.

Reader view is great in Safari too, but both are designed to filter content as well and often drop things that shouldn’t be dropped. And Safari’s behavior is intentionally obfuscated, even developing to support it can be a crapshoot.

For websites like this I always use the sakura css bookmarklet https://oxal.org/projects/sakura/bookmark/. I really appreciate the author lets me and everyone else read their blog the way I like.

This is just terrible. This weeaboo stylesheet adds HUGE left and right margins and the spaghettifies the text into column slender as sakura, doh.

I personally find text with huge margins easier to read than text without, but that's just me.

This worked great for me on my iPhone. Admittedly it was a pain in the butt to add the bookmarklet to my actual bookmarks, as you can’t long-press to copy it.

Quick and dirty option...

hop into the chrome dev console and set body width to 80ch and margin-left to somewhere around center of your screen.

I love the minimalist nature of it. No fluff and straight to the content.

I always learn something anytime I read Dan Luu, even (or particularly) when I have read it before.

Wow, I had a very similar early years to Dan. I also did the "learning to code as a teen" thing that didn't really work out, other than to establish an interest. I also did EE, which was nice in that for the first time I had an overview the whole way down to the silicon.

The big revelation for me though was that you can learn anything yourself. You also don't need to be able to do exam questions to understand something, although you need some maturity to know whether you get it or not. I can almost pinpoint when it happened: I went to a tutorial with a grad student who nonchalantly explained that he was going to read the whole syllabus on biomedical engineering in the next few weeks, by himself.

Armed with that, I started my first job in finance. I read a lot of books those first few years, textbooks, biographies, histories, everything. The econ/mgt part of my course didn't really say anything about bonds and derivative pricing, but I found the relevant texts. It helped a lot to have done math heavy courses, but I still ran into new things like stochastic calculus.

Concurrently I discovered that a lot of things were getting automated, so I'd better learn how to actually code (my degree actually did go through DS&A, but I had no idea I'd need it). This was more gradual, as the prestige job in finance is trading, not coding. But as time went by it became increasingly clear that if you couldn't code, you narrowed your future opportunities by a lot. These days I'm coding every single day, and most of my issues are coding issues, not trading issues.

> In conclusion, life is messy and I don't have any advice.

Lol, refreshingly honest.

>"The Joel Test is now considered to be obsolete because it awards points for things like "Do you have testers?" and "Do you fix bugs before writing new code?", which aren't considered best practices by most devs today"

"Most devs" today are busy producing megatons of JS code with gigatons of external dependencies on things like LTrim().

btw my wife consults for a company that does nothing but software testing for 800lb gorilla companies. The business is striving. I guess they did not know that they should get approval from "most devs" first.

I don't understand why 'fixing bugs' before writing new code isn't still a best practice?

Perhaps because of this Bill Gates quote? "There are no significant bugs in our released software that any significant number of users want fixed. … I'm saying we don't do a new version to fix bugs. We don't. Not enough people would buy it. You can take a hundred people using Microsoft Word. Call them up and say 'Would you buy a new version because of bugs?' You won't get a single person to say they'd buy a new version because of bugs. We'd never be able to sell a release on that basis."

"I was hesitant about taking the job because the interview was the easiest interview I had at any company4, which made me wonder if they had a low hiring bar, and therefore relatively weak engineers." Reeks of paul graam cultism.

> People like a good narrative. One narrative people seem to like is that I'm a good problem solver, and that problem solving ability is generalizable. But reality is messy. Electrical engineering seemed like the most natural thing in the world, and I picked it up without trying very hard.

Narrative or not, my experience talking with people transitioning from other careers via bootcamps has been that people who came from scientific backgrounds have a very large advantage over those who do not.

I would say people who are good at languages have an advantage, but that’s a wide definition.

Math is the most transferable language and anyone in the sciences has a solid math background.

The biggest prerequisite, though, is a love for computers.

I’ve been trying to teach my 16 year old nephew to code. He’s an excellent student, great at math, and has made marvelous strides in music (should be very transferable), but his computer literacy is shockingly low. The kid barely knows how to install a program on his laptop. As a result he hasn’t engaged with it like he did when I started showing him stuff on the piano, and has made no progress at all.

I think love seems like a pre-requisite because of the massive time investment required to become good, but I know really good software engineers who couldn't care less about computers. They just realized they could triple their salary working at companies like Google and so buckled down and learned the skills they needed to get those jobs and then climb the ladder.

Most people don't have that kind of discipline and drive, so interest is a good supplement, but I don't think you actually need it.

A piano with MIDI (USB preferably) and something like Ableton Live might work. Get the full Max and you can code your own devices.

https://cycling74.com/products/extendmax

Even Max4Live has Node, so it's not exactly limited if you don't want to spend the extra money on Max.

Really enjoyed the childhood part. The whole smart but won’t necessarily “succeed” until you find what you think is cool… really got me with the “yucky” comment on memorizing math

@dang - This should probably have a (2016) in the title.

i read a lot of books in two weeks. i read a lot of open source code libraries.

then i do side projects constantly.

i still feel like an imposter.

Reply on news.ycombinator.com