glynnormington

That's hard. My only advice when working in a stifling, corporate environment is to find out what your education budget is and then use it for the kind of learning I was referring to in the article. (If you don't have an education budget, that's one more reason to start planning a job move...)

Did you see this helpful link: https://littlegreenviper.com/testing-harness-vs-unit/. According to that usage of "test harness", it's not the same as a unit test. It's a way of driving code manually to explore different usages and to recreate certain kinds of bugs. It is used to complement unit tests.

I try to think in terms of owing the dependency a contribution as a small payment for using it, and this bugs me until I do it. But, sure, better to contribute docs sooner rather than not at all.

(One advantage of deferring is that the contribution may be better quality when I've had more experience of using the dependency.)

Fair point. I often copy stuff across from one project to the next. But this point is most relevant when I'm using another language etc. for the first time and I'm tempted to try to retrofit all my previous best practices.

For example, I used to work on a mainframe product that dumped the address space to disk on a crash. Then it was possible to build all sorts of fancy tooling to analyse the dump. When I moved to a different platform, without those kinds of dumps, it was tempting to try to reinvent all this stuff, but it would have been a massive time sink (and would have failed too).

If there's a definite performance problem and a simple solution, then sure, go ahead. But applying every optimisation that comes to mind can produce a dog's breakfast of unmaintainable code and then when a real performance problem comes along, it can be really hard to fix.

Nice - thanks.

I take your point as I'm retired. But I had my previous working life squarely in mind when writing the post.

"Sustainable pace" helps, which in my case came down to 37 hour working weeks, not working at weekends, and taking all my vacation (and some extra when my employer let me buy it). I know this might sound like madness to Americans, but as a Brit employed mostly by American companies, it worked fine for me.

I found that taking plenty of breaks during the working day helped. Coffee breaks with colleagues, a decent lunch break (ideally including exercise), and plenty of tea breaks. So many times I've had a good idea or solved a problem during a break, so they are actually productive.

Then there's finding other useful things to do which aren't as taxing as the thing that's blocking you (e.g. the next large feature). Fixing bugs, writing docs, and doing preparatory investigations about the upcoming work are all productive ways to give yourself a bit of a mental break. (This was hardest when working in teams with continual short sprints or doing XP and pairing, but if I allowed myself to start to burn out, my productivity started to decline - essentially my brain was forcing me to take things a little more slowly in order to recover.)

I like that. There are other ways of capturing work in progress adjacent to the code, instead of writing a journal. One of my favourites is to write a failing test - pretty much impossible to overlook or misunderstand on "re-entry" to the task.

Another is to write a temporary commit log, with "WIP" in the first line and a TODO list in the rest of the log. This is good for ephemeral information that would just clutter up the code.

If I do need something like a journal, I have occasionally just written a private gist and put that in a tab on my browser.

Feel free to submit a PR. :-)

That was one of the points of the new repo. A plain text version of the file is https://raw.githubusercontent.com/ai-robots-txt/ai.robots.tx...

The other point was to make this community maintained rather than rely on one source to provide all the inputs.

This project generates some tests of non-deterministic features of JSONPath using Haskell's list monad.

The underlying technology, https://gource.io/, has probably been mentioned here before, but it's a superb tool which produces beautiful animations, so deserves another airing.

These are the top ten technical books I can't bear to part with. What are yours?

These days there are several aspects of software development that we take for granted. Perhaps we don't know how we'd manage without them. But it wasn't always that way.

An introduction and overview of the state of the art and work in progress. Discussion at: https://fosstodon.org/@underlap/111652832812061992

Have you worked with anyone like these people?

I provide a dependency diagram so students can work out where to apply most effort and how to catch up if they miss something.

I also show likely dependencies from the course assessment to the various topics. For instance, there is a strong dependency on the IO monad, but a weaker/optional dependency on (general) monads.

In terms of presentation order, I tend to over-simplify early in the course and circle back and make things more precise later.

(I'm teaching a 2nd year university course on Functional Programming with Haskell for the first time, so I found the OP fascinating. Thanks!)

Really "An Immutable Rope in Go". (Raised https://github.com/deadpixi/rope/issues/2.)

Excellent! Two updates since it was written: use main rather than master for the default branch; use git switch to change or create branches.