There are a lot of great open source software tools, but that blanket isn’t enough to cover you. Having the best tools money can buy includes support contracts (possibly to upstream devs), service management (datacenter or various IaaS/PaaS services) and excellent dev hardware (laptop?)

I agree with the changes to (2) and (3).

The change to (7) seems to misunderstand what Joel originally meant by spec, which is a more thorough formal communication than at least the vast majority of automated specs or “BDD” implementations I’ve seen in the wild.

The changes to (6), (8) and (10) seem to be direct disagreements with Joel.

1. tabs (and all other invisible characters, see dos2unix) have consistently proven to be difficult-to-understand and error-prone among computer users
2. resizing is easy in an environment you’re familiar with, but in practice people often operate in environments that they are unfamiliar with, so the lowest common denominator (i.e. what I can do without thinking in Notepad.exe) wins.

The biggest problem is that they get mixed inadvertently. Go has shown that a program can actually fix it. As a result, my editor reads tabs, I often type spaces, and gofmt makes it standard tabs on save. This is legitimately the best feature of the Go tool chain.

Years ago when I programmed in Python, there would always be that one committer who would insist on tabs, or use 3 spaces instead of 4 in some places, and all hell would break loose in the commit history–annoying, but not the end of the world. The shameful person, btw, didn’t do the cleanup, cause they didn’t give a shit.

In summary, this is the least of our problems and can be automated incredibly effectively if it means enough to you, but if not, who cares?

The problem is the assumption that allowing it to be resized is even desirable in the first place. If you are working on a specific codebase, you need to stick with the style that the codebase dictates. Imagine if people thought it was a good idea to allow “flexible brace styles” to let you use your preference. Why must indentation be different?

If you want the code to be displayed differently according to your preference, it should be implemented as a rendering-time hack (for instance, showing “lambda” as “λ”, etc) rather than changing the actual bytes on disk. Rendering 4 spaces on disk as 8 spaces on screen is a trivial config change in any decent editor.

Some languages are whitespace sensitive and a tab doesn’t always represent the same number of characters so making everything done with spaces is the simple, easy way out when dealing with vertical alignment. Gofmt does vertical alignment pretty nicely and it works well across different editors and even with doublewidth characters involved etc but most developers don’t like using a formatting tool outside of what its editor does on its own and most languages don’t even have an agreed upon format so there lacks formatters for those languages, because adoption would stumble.

Also, if you follow a convention like “maximum line-length 80 chars”, …

In order to allow tab characters in your code, you have to disallow certain coding styles to prevent misalignment when tab sizes change. It’s much easier to simply disallow all tab characters, especially as the team size increases.

Ruby’s been around for 21 years, and Python for 25. It doesn’t seem unreasonable to expect them to still be around in another 25, even if they aren’t getting new language features and are just being updated to keep running on new OS versions.

Lisp is 58. There will be Perl and TCL scripts around until cockroaches conquer the world, and I’m quite certain a few Rails 2.0 apps will still be puttering along for at least the next few decades, to say nothing of frankenstein upgrades of Struts and other Java frameworks.

Things that are “old” in the computing world are still around not only because they are still useful, but because change is difficult.

I fully expect someone, somewhere in 2066 to be writing virtual augmented social reality software on Mars with common lisp and complaining bitterly about how stupid and retrograde all the languages that the robots use to talk to one another are.

Heck no! In the mainframe world you find a bunch of them. As usual, it depends on what you consider ‘staying power’, but I would add to that list: PL/I, JCL, NATURAL/ADABAS, SAS and RPG (for the AS/400).

I disagree. Once a programming language is popular enough, it’s basically around forever.

In 50 years JS, Ruby, and Python will be in the same position as Cobol today. Nothing new and exciting going on, but there will be plenty of big systems that work well enough that are too big and expensive and risky to replace, but require maintenance and upkeep.

compared to maintaining (and testing) half a dozen package formats for different distros.

Again with that bullshit. Let. Packagers. Do. Their. Jobs.

I’m torn on this. On the one hand, yes. Having 3rd party packagers is great for pretty much everyone and ideally f/oss software organizations should maintain and license their software so that repackaging is possible.

The problem with this view is that user maintained packages lag upstream, often by quite a lot, and as an engineering org having lagging user packages means having to deal with innocent users who are stuck with fixed bugs. See a classic rant on this from jwz.

So yes. By all means I want package managers (or /opt monodir installs) so I can uninstall your software eventually and update it sanely along with everything else, but really that means that the developing org does have to take on packaging responsibilities or else pay the costs associated with not taking them on. For all that I dislike curl | bash, it definitely seems to be a local optimum.

Disclaimer: this is my view as a user, I’ve never participated in the community as a (re)packager or distributing an original package except in publishing Maven artifacts which don’t require repackaging and thus don’t count.

Again with that bullshit. Let. Packagers. Do. Their. Jobs.

I certainly agree with letting packagers do their jobs. However, it seems many users see this as the project’s responsibility, rather than the distribution’s. I read this part of the post as being about that sentiment.

This has come up before - https://lobste.rs/s/ejptah/curl_sh

I still haven’t seen a strong argument against this mode of installation, but I still hear a lot of “you’re doing it wrong” anger. I’d be very interested in a cogent argument (comment or link pointer) about why this is bad, as it feels to me like the culture has been shifting in the direction of curl | sh

Shell-based installations for people who want to run the “arbitrary” code from the developers doesn’t prevent you from using packages and dependency management. What’s the problem here?

Again with that bullshit. Let. Packagers. Do. Their. Jobs.

“Software should only be distributed through official distro channels” (the only consistent interpretation I can find of your statement) is far from universally held idea, so I’d expect an opinion stated this forcefully to come with some reasoning.

Unfortunately I would imagine if most packagers were just doing their jobs (as in employment that pays their bills) they would have no time to update packages.

I don’t care what your project is, if part of the installation process calls for running arbitrary shellcode, I’m never, ever going to run it.

a) linux only, b) 64bit only, c) includes shellcode in the shell script it runs, d) sets scary sysctls, e) sets dev-mode by default, g) is hella interactive

• a, b: These have nothing to do with whether curl | bash is secure.

• c: Trusting an upstream to provide you a safe program but not a safe installer is security theater.

• d, e, g: Probably bad, but doesn’t have anything to do with curl | bash in particular.

…besides digits and hyphens and full-stops, what did you want in your versioning system?

Because both this and SemVer are designed to provide reliable information to automated systems, simpler systems tend to be more reliable, and a good way to limit implementation complexity is to limit the complexity of the inputs the system must process.

ASCII has the advantage of being very simple, widely implemented, and broadly compatible with non-ASCII systems, so it’s an excellent choice for machine-readable data.

Actually, I have an interesting data point there. I just had a friend join me at Google, after they’d spent more than a decade at a large defense contractor well-known for both software and hardware. Google’s interviews are famous for involving algorithm questions - slightly more complicated than linked-list implementation, but it would be hard to pass them without knowing it as background knowledge. The other company’s are not.

According to my friend, many of the highly productive programmers they know from the other company will cheerfully talk about how glad they are to leave their undergrad algorithms courses in the past and forget everything from them. Googlers… have a contrasting attitude, which was a large factor in coming here for this friend, and for myself.

My conclusion is that whether data structures and algorithms knowledge is important to programmers depends on the nature of the work, and is also a culture question. It would be a surprise here to meet a coworker who wasn’t at least interested in discussing algorithms topics, even though they are only occasionally of direct importance.

Depends on the work you’re doing. Plenty of developers can do their jobs perfectly well without understanding fundamental data structures.

It would seem impossible to do effective performance analysis & many other tasks without understanding how basic data structures & algorithms work, though.

It’s important to know how it’s implemented, so that in the event you find yourself using one (even if it’s fundamental as in erlang or in a stdlib somewhere), you understand its characteristics. Actually performing the implementation is, however, as you say, utterly pointless now, just like implementing any sort or any tree.

As just one data point, I am a Ruby programmer of 4 years now and I do not know how to implement a linked list.

If the answer is “no”, should they know how to implement anything? On the other hand, it seems really strange they asked for it to be implemented in Java.

I wouldn’t expect them to know all the details off the top of their head, but it’s not a very difficult problem at all. Even if they’ve never heard of linked lists before, they should be able to code it up once they know it’s a series of linked nodes. It’s not like they’re asking for some exotic balanced tree with tons of pointer juggling.

That said, 30 minutes to implement the whole List API for a junior developer is a little tight. Hearing it was 25 public methods sounded unreasonable, but looking at the docs, most of them are just wrappers around some variation of a while(…) loop, so it ends up not being too bad. If I had to use it as an interview question I’d probably bump it up to 60 or 90 minutes, though.

I’d be interested in seeing the code the author and his co-workers came up with. 6 hours seems like a really long time to not get the whole thing working.

Ignoring the 2edgy schtick below, there is a good point to be made about learning the tools we have.

I watched a pretty good developer write ~50-75 lines of C# to iterate through all files in a directory, open only those ending in .XML, and change <foo>bar</foo> to <foo>baz</foo>. This took him about 15 minutes, between reading the manual (was String.Replace needle, haystack or haystack, needle…), testing it, etc. He was stunned when I showed him that the Cygwin shell on his Windows box let him do this in literally one line.

I also remember being schooled by an old UNIX-head who, after seeing my hand-rolled Ruby based data transformer, proceeded to bang out one that was faster, more robust, and probably a tenth of the code with judicious use of paste, cut, tr and sed.

There’s nothing wrong with reimplementing a tool for the purposes of learning, for sure - but I think lots of people could benefit from digging in to the tools we’ve got at hand and learning them well before writing something new.

I’ve read about one problem with curl | sh: if curl fails with an error in the middle of a download, the incomplete script is still sent to sh to be executed. So a line “rm -rf /usr/bin/some-app” might be truncated into “rm -rf /”. The solution is to download the file completely first, and then run it with sh.

However, this blog doesn’t look like it thinks failing downloads are the only problem with curl | sh.

My knee-jerk reaction for a very long time was to be shocked and appalled by this practice. “What?! I have a carefully curated list stored inside my apt-key!” – really? How’s your chain of trust? How many key-signing parties have you been to lately? Did you chroot that arbitrary code you pulled from github before you ran it?

If you’re using vanilla Debian then one can’t become a packager without having had one’s key signed by a member of the project (which they’re at least supposed to check your identity against a government-issued ID before doing - certainly the two who signed my key did), and those packagers in turn are supposed to read the source/changes before packaging (which happens with a script they write, not something from upstream). No way to guarantee that they are, but that’s what signing off on it’s supposed to mean, and everyone I’ve known has taken their duties seriously.

The people who write code that works with curl | sh surely know about the security risks, and continue to use it - in part because the alternatives are much worse (from a usability perspective).

It depends entirely on the company. The only real way to try and determine whether these things occur at a given company is to ask the people that work there questions to that effect. Really, the best way is to work there, but this is a solid second-place choice ;)

Questions to ask during the interview process to suss out details (by applicable question number):

• 2) What does the process for committing code look like? How effective is it/how often is it followed?
• 4) What’s your least-favorite project you’ve been on since you’ve started?
• 10) What kind of hardware do you develop on?
• 17) How well do you feel like you understand the company’s direction?

When spread out over several different interviewers (who likely aren’t communicating their specific answers between each other), you can start to get a good idea of what the people that work there really think about their company.

The interviewers probably won’t lie to you outright (would you?), but they may not tell the whole truth either. Asking a bunch of times gets you answers you can synthesize into a picture of the environment. If things sound too shady, or you can’t get a straight answer, passing on the job might be a good idea!

Edit: Asking these kinds of questions is always a good idea, as well. Not only does it get you a good idea about the company as a whole, but it marks you as somebody who’s actually thought about the kinds of things they’d like to see in a company. From first-hand experience as an interviewer, this makes a great impression!

There’s a little truth in all of them, but the ones I see most commonly are #1, #4, and #14.

As someone who is working in a start up, has worked in 2 previous start ups, several months at enterprise, one tremendous personal failure, and has friends in start ups around ~10-20 people that are vocal about the problems. I will say that you will encounter at least a few of these. A company that has all of these is a company you should leave immediately without question.

If you are planning to work in this wonderful profession (no sarcasm, this is a beautiful profession with the right people) for many years, be prepared to:

• Work for someone who won’t treat you the same way a recruiting document may suggest.
• Work for someone who has little to no understanding of software development.
• Work for someone who has little to no understanding of how to build a team.
• Be in a situation where the business is struggling and stress becomes a daily thing.

Also remember as you work, you change and develop new perspectives. You will also inevitably make mistakes and see a new side to people.

Ideally you never have to deal with any of these, and you can focus on building awesome things that explore your creativity as well as the needs of people you care about.

#3 gave me flashbacks! both the ETA crap, and interrupting me to explain how I was solving the problem (for no very good reason other than the warm fuzzy illusion of managing the effort)

At my last place, 1,5,6,9,10,19 & 21 are pretty spot on unfortunately.

Bad management is very widespread within sv / tech companies, because fast-moving companies inevitably end up with managers with little experience/training.

You can dodge some of these issues by working for larger / more-established companies, but even the most well-respected companies have bad managers thriving on some teams. Sometimes top-performing teams can be managed by complete assholes of some form or another (e.g. many of the stories about Steve Jobs).

Learning to “manage up” with inexperienced managers, or change positions when the situation is untenable is a reality of business, and not unique to tech.

Just to be clear, though – this is a managerial problem and not something you should suffer through! There are plenty of fantastic people out there to work for. As a tech worker you hold sway and can try to seek out places that don’t have these antipatterns, and work to reverse them when you see them.

The purpose isn’t (just) to teach beginners. It’s to show other Rubyists exactly how I do things. There are five or six tools that help you install Ruby, and I’ve shown you the one I use.

The article’s critique was anchored specifically on the comments of the founders of Paypal, Facebook and 42Floors. “No money, no likely revenue, and nothing holding you accountable” doesn’t really seem to apply.

Bio-tech startups would seem to have diversity problems that mirror those of software startups fairly closely.

Bio-tech startups certainly don’t work this way.

Are you sure?

I don’t remember ever hearing anyone say

There are certainly efforts in other fields to encourage more people to get into them.

But, and maybe this is just personal bias, chemical engineering does not underlie so much of modern socio/political/economic power in the way that software does. Software is eating the world, and without some kind of base literacy, it’s increasingly hard to understand what’s going on around us. That’s why I think more people should have at least a tiny understanding of how computing works.