Same here.

I’d love to have a fancy mechanical keyboard with lots of option keys etc. but I don’t have endless spare time to research let alone configure something like that.

The MS Natural 4000 is perfect for me: I went from pain after an hour to no pain no matter how much I type. It’s only $30! Great stuff.

I’ve got an ergodox, but getting used to the thumb keys at work but not having it on my laptop at home was just too much to get used to.

Several essentials have made a disproportionate benefit on my career. In no order:

• find a job with lots of flexibility and challenging work
• find a job where your coworkers continuously improve themselves as much (or more) than you
• start writing a monthly blog of things you learn and have strong opinions on
• learn to be political (it’ll help you stay with good challenging work). Being political isn’t slimy, it is wise. Be confident in this.
• read programming books/blogs and develop a strong philosophy
• start a habit of programming to learn for 15 minutes a day, every day
• come to terms with the fact that you will see a diminishing return on new programing skills, and an increasing return on “doing the correct/fastest thing” skills. (e.g. knowing what to work on, knowing what corners to cut, knowing how to communicate with business people so you only solve their problems and not just chase their imagined solutions, etc). Lean into this, and practice this skill as often as you can.

These have had an immense effect on my abilities. They’ve helped me navigate away from burnout and cultivated a strong intrinsic motivation that has lasted over ten years.

One thing that I’ve applied in my career is that saying, “never be the smartest person in the room.” When things get too easy/routine, I try to switch roles. I’ve been lucky enough to work at a small company that grew very big, so I had the opportunity to work on a variety of things; backend services, desktop clients, mobile clients, embedded libraries. I was very scared every time I asked, because I felt like I was in over my head. I guess change is always a bit scary. But every time, it put some fun back into my job, and I learned a lot from working with people with entirely different skill sets and expertise.

I don’t have much experience either but to me the best choice that I felt in the last year was stop worrying about how good a programmer I was and focus on how to enjoy life.

We have one life don’t let anxieties come into play, even if you intellectually think working more should help you.

This isn’t exactly what you’re asking for, but, something to consider. Someone who knows how to code reasonably well and something else are more valuable than someone who just codes. You become less interchangeable, and therefore less replaceable. There’s tons of work that people who purely code don’t want to do, but find very valuable. For me, that’s documentation. I got my current job because people love having docs, but hate writing docs. I’ve never found myself without multiple options every time I’ve ever looked for work. I know someone else who did this, but it was “be fluent In Japanese.” Japanese companies love people who are bilingual with English. It made his resume stand out.

Four things:

1. People will remember you for your big projects (whether successful or not) as well as tiny projects that scratch an itch. Make room for the tiny fixes that are bothering everyone; the resulting lift in mood will energize the whole team. I once had a very senior engineer tell me my entire business trip to Paris was worth it because I made a one-line git fix to a CI system that was bothering the team out there. A cron job I wrote in an afternoon at an internship ended up dwarfing my ‘real’ project in terms of usefulness to the company and won me extra contract work after the internship ended.

2. Pay attention to the people who are effective at ‘leaving their work at work.’ The people best able to handle the persistent, creeping stress of knowledge work are the ones who transform as soon as the workday is done. It’s helpful to see this in person, especially seeing a deeply frustrated person stand up and cheerfully go “okay! That’ll have to wait for tomorrow.” Trust that your subconscious will take care of any lingering hard problems, and learn to be okay leaving a work in progress to enjoy yourself.

3. Having a variety of backgrounds is extremely useful for an engineering team. I studied electrical engineering in college and the resulting knowledge of probability and signal processing helped me in environments where the rest of the team had a more traditional CS background. This applies to backgrounds in fields outside engineering as well: art, history, literature, etc will give you different perspectives and abilities that you can use to your advantage. I once saw a presentation about using art critique principles to guide your code reviews. Inspiration can come from anywhere; the more viewpoints you have in your toolbelt the better.

4. Learn about the concept of the ‘asshole filter’ (safe for work). In a nutshell, if you give people who violate your boundaries special treatment (e.g. a coworker who texts you on your vacation to fix a noncritical problem gets their problem fixed) then you are training people to violate your boundaries. You need to make sure that people who do things ‘the right way’ (in this case, waiting for when you get back or finding someone else to fix it) get priority, so that over time people you train people to respect you and your boundaries.

The biggest mistake I see junior (and senior) developers make is key mashing. Slow down, understand a problem, untangle the dependent systems, and don’t just guess at what the problem is. Read the code, understand it. Read the code of the underlying systems that you’re interacting with, and understand it. Only then, make an attempt at fixing the bug.

Stabs in the dark are easy. They may even work around problems. But clean, correct, and easy to understand fixes require understanding.

Another thing that helps is the willingness to dig into something you’re obsessed with even if it is deemed not super important by everyone around you. eg. if you find a library / language / project you find fun and seem to get obsessed with, that’s great, keep going at it and don’t let the existential “should i be here” or other “is everyone around me doing this too / recommending this” questions slow you down. You’ll probably get on some interesting adventures.

Never pass up a chance to be social with your team/other coworkers. Those relationships you build can benefit you as much as your work output.

(This doesn’t mean you compromise your values in any way, of course. But the social element is vitally important!)

Couldn’t disagree more – the most successful team I was on was heavily into XP. When people say it’s heavyweight, they’re usually talking about pair programming. I’m not sure what people have against it; I’ve found it’s a great way to train junior developers, awesome for tricky problems, and generally a great way to avoid the problem of, “Oh this PR looks fine but redo it because you misunderstood the requirements.”

Why I like XP over anything else is the focus on development practices rather than business practices. Pairing, TDD, CI, <10 minute builds, WIP, whole team estimation, etc are all used to produce a better product, faster.

The weekly retrospective offers a way to adjust practices that aren’t working and bolster those that are.

Agreed 100%. It turned my head a bit when he thought Agile was too prescriptive, but then was considering an even more prescriptive methodology.

What was your experience with XP? Also, scrum is heavyweight as well in my experience and doesn’t work excellently in an actually agile environment like a startup. Feels like it could work in corp. though.

Brown further developed the course - CSCI 1730 based on a revised version of PLAI (and an early version of typed racket) with video lectures and assignments.

PLAI’s spiritual successor Programming and Programming Languages is also available based on a new language called Pyret.

Let me be the first. :) I love pair programming, and miss it whenever I have to code without it. Doing it for a year kind of ruined me for working alone. (And I’m not an extrovert! In general, I shy away from being around people.)

I read about bad pair programming experiences and count myself as lucky that all the partners I had were really great people and invested in the process. I can see how it could go sideways.

I would be interested to know if the authors team consistently concludes during regularly scheduled retrospective sessions that everyone enjoys doing forced pairing enough to keep it a thing.

Pairing was already a part of the culture when I originally joined, so it was actually pretty hard to get people to admit they didn’t enjoy it (politically unpopular). It was never brought up in retrospectives. That said, I’d say the majority of the people who worked there did enjoy it and it worked well for them.

I respectfully disagree.

I specifically wanted to avoid the conversation of productivity (happiness is a more humanitarian metric, and therefore more important to me), but here we go:

I’ve paired full time for the last five years on complex banking software - I’d say unless you’re doing simple CRUD, it’s more like “pairing, take the productivity of two devs and multiply it by 4”.

I was pairing on a payment gateway, so similar problem space (not easy). I found no such productivity multiplier. In fact, I was frequently (and silently) bemused when I noticed “odd” programmers completing far more work than their pairing counterparts. I’m still amazing that people try to say that dividing your work-streams in half yields higher efficacy. The math just doesn’t add up here, even in a world where everyone learned by watching people code.

Not only that, but pair rotation means we see no burnout on really hard tasks and tech debt. Normal companies I’ve worked at only have the stamina for either minor tech debt or “scrap it and start over”. Both are terrible choices for long term productivity. The real value is in massive tech debt projects accomplished over months, without a loss of functionality or features. Pairing enables that where single developers just can’t handle the boredom.

You’re creating a false dichotomy where you can choose between pairing or tech debt. Tech debt is equally prevalent in both XP and non-XP worlds. Also, anecdotally, I am living proof that burnout is possible with pairing. :)

Also, pairing is a skill that is as separate from programming as touch typing.

No argument here!

A good way to learn, which schools seem to mostly ignore, is to repair something which is broken. I guess they assume you will come across enough of your own bugs, but guaranteeing that the students see certain kinds of failure is useful for making specific points and showing specific interactions.

Plus, the detective mentality is useful on its own and should be fostered wherever possible.

I have often met professional programmers that don’t really care about how anything they use actually works.

Do you meet the other kind at all? I tend to use sentences starting with “I have often met” for things like not liking triply-nested expressions. For not caring about how dependencies work, the situation seems bad enough that I tend to say: “I’ve heard in distant lands of the odd savant who understands some internals of their dependencies more often than not, but of course everyone can’t hope to meet such a person themselves.”

At best I meet people who understand the internals of some single project that they are active with the community of. But while they may have poked around inside Vim, they’d know nothing about their network stack or browser or compiler.

This assumption is kinda central to my life, so if I’ve just been really unlucky I’d really appreciate pointers on where to find such people.

I wrote this for the many people I know who already have a college degree but cannot find sufficient employment. Either their degree was worthless, or it was in a field that has more people than jobs, or both. Many of them are willing to work hard, but just don’t even know where to start or what to do. I believe the programming field right now offers a place for those who are willing to work hard at learning and self-improvement.

Sure, if you are a high school graduate and considering this course verses going to college, I would probably lean towards a cheap CS degree. Many great CS degrees cost 30k+ a year. If that was my only option, I would skip the degree.

What I’ve done in the past is build “everything,” with build caches and aggressive dependency markings. If you’re at the scale where having a monorepo is genuinely a pain, the it’s time to get a sane build system (literally out-of-the-box Gradle works fine if you just have Java/Kotlin, for example, but something like Bazel/Pants/etc. works great for more generic workloads), at which point the builds that don’t need to happen will be no-ops, and you never need to worry about forgetting to rebuild/upgrade something.

For me, this is really coming down to trade-offs. Configuring something like Bazel or Pants (or even potentially Gradle at the scale we’re talking) does take some effort. The advantage, to me, is that you either will end up doing this anyway with multirepos (at which point, you might as well have a monorepo where you can monitor all the changes anyway), or you handle all the upgrades piecemeal and bespoke, at which point it’s gonna be really tricky to ensure you’ve actually upgraded everything. In other words, we’re trading human steps for automation: if you’re at a size where you “need” multirepos, you’re also at a scale where automating all of this will be a huge win, which in turn, IMHO, negates needing multirepos.

The chromium project uses the analyze functionality of gn (initially implemented in gyp) to determine which test binaries are affected by a change and only build/run those tests. Since this relies on the gyp/gn dependency graph, various checks and whitelists are added to cover edge cases. This, combined with the task-deduplication abilities of Swarming heavily reduce the load of ‘building everything’ in a monorepo. For Swarming, test binaries are compiled in a deterministic way so the same code produces the same SHA, if a SHA already ran and succeeded you don’t need to run it again.

We use Teamcity, and it has a way to make triggers only work for a regex of directories. So, only commits to X subproject trigger builds of X.

What can I do?

Avoid working in Japan, for starters.

I think this is a pretty common pattern. Taking the “learning Haskell is like re-learning programming” metaphor seriously, this would be like learning Python but feeling infinitely compelled to dig into the VM implementation and how that all hits metal.

The cure to both I think is just to have concrete goals of making something happen. Practice building a small project in Haskell but aim to produce a concrete project result as efficiently as possible measured in your own time and sweat. Huge aspects of Haskell will be penalized merely by you not being familiar with them—but an IO-bound implementation written in an imperative style probably is easily obtainable.

Then from here, make an iteration and improve something. Carve off a small piece of the application and generalize it. Ask for help leveraging types and purity to constrain some pieces.

I think an approach like that can be very successful.

As tel notes, you really need to unlearn your existing views of computation a bit before you can start to grok haskell.

The problem I see is that a lot of people really have a hard time with that one thing. Haskell is oddly easy to use once you start to let go of the notion that computation has to be a series of steps. It is rewarding though, honestly I was at flipping tables stage with computation in general and learning Haskell and Idris have completely made me fall back in love with things. Just my $0.02

Great point on the synthesis front. We get close, but despite having full control over semantics, runtime and everything else, can’t always guarantee a suitably high-level cost-free abstraction (Rust doesn’t count).

Related: overheard the clerks at the grocery store lamenting how their automatic doors sometimes open randomly of their own accord. They were getting extremely cold from the air blowing in. I chuckled, but then realized: if we can’t get automatic doors to function correctly 100% of the time, then we have a long way to go.

I agree with this point, and can add the example of Sql. We still can’t turn ORM queries into performant Sql. Or optimization. I have been working on integer optimization for our banking software, and it falls apart after just a few thousand requirements. There are very real, very hard edges to what we can currently automate in software, and most are closer than we think. Optimization is a perfect example. If it takes my integer optimization project 45s to max which 6 cards with 2 attributes and 3 upgrades of 9 types to buy (9 constraints of 45k options each) then it is light years away from intelligently converting high level synthesis of hardware or ORM queries.

This is why we get ridiculous “expressiveness improvements” like type-level Peano arithmetic, HLists and the like, that allow you to enforce ever more sophisticated invariants - so long as your data structures don’t cross process boundaries.

Far more promising results would be obtained (and probably for less effort)

however, it would offer bigger productivity gains than yet another statically verified implementation of self-balancing search trees or whatever.

I don’t know why you are bringing up type system expressiveness as if it is diametrically opposed to crossing process boundaries. Being able to enforce these properties on a single process is a prerequisite for being able to enforce them on multiple processes.

type technology to enforce that multiple processes, possibly running on different machines, exchange data safely

There is plenty of research in this area. I don’t have the time to prepare a survey, but Global abstraction-safe marshalling with hash types (ICFP 2003), its realization into a more complete PL Acute (ICFP 2005), and Proof Carrying Code (POPL 1997) are good places to start.

For example, as someone who plumbs data back and forth between database servers and GUI clients (read: writes CRUD apps) for a living, I would be delighted with a type system that checks whether the data model in my application code agrees with the data model in the database server.

Ur/Web is an interesting experiment in that direction.

I agree with the “20” minutes. But I disagree with covering such broad subject matter, and so shallowly (perhaps he meant something different).

I think you’ll learn a lot more by doing things end to end, and start to finish. Figure out a small idea for a program you want to create. It should be highly relevant to you or someone you care about. Build the whole thing, including the UI, the backend, the database, tests, deployment, monitoring, etc etc. Use it. Polish it and make it robust. Don’t stop putting time into it until it’s actually done.

I think perseverance is what makes expert programmers so unique. They can hit problems they’ve never seen and push through without getting discouraged. The only way to learn that is by finishing whole projects, not starting new ones.

How do you balance reading a chunk of e.g. SICP and then coding, presumably something relevant, in 20 minutes? How much would you typically read? Does this only work because you do it every day? Or is it because the texts come with relevant exercises, so you don’t have to come up with your own projects?

What did you think of Data Scientist’s Toolbox? I’m curious how resources there feel. Did you have an applied math background going in?

The book Software Foundations came up when people were talking about learning to do stuff like seL4. I noticed it’s Coq where seL4 and many good projects are Isabelle/HOL. Curious if you or anyone else can tell me if Software Foundations' material also covers most of knowledge or skill needed for HOL, too. It plus a HOL-specific tutorial or articles. Or is it and Coq’s approach different enough to need a whole different book?