matfil
I did admit this was controversial! But it fits in with a more general view that there are a lot of tools which make good servants but poor masters. Auto-builders are a good thing, partly because (as you say) they can help to clarify what is required to make a build, and partly because (especially for dependency-heavy software, which seems to be the norm nowadays) they can help catch things quickly when the dependencies shift beneath you. Making them a hard gate on releases seems a little too close to making the tooling your master, though.
(Somewhat separately, I also worry about CI acts as a hiding place for complexity. Sometimes it reaches that point where nobody knows how to make a build without the CI tool any more. Then local testing and debugging becomes difficult.)
I guess another controversial opinion: this is a problem with the idea of CI (or at least how we work with it and what we expect to get out of it), rather than the idea of randomized tests.
A valid answer might be "nowhere". Code review is a hot topic at the moment, but I'm pretty sure a lot of software I've found useful over the years was created with little or no formal review, and I think we should at least consider the possibility of leaving trustworthy developers to work without constant oversight.
Articles telling us to focus on team, rather than individual, productivity should probably be viewed through this lens.
I think "going into the weeds" (and not being afraid to do so again, in another context) has some value independently of any specific patterns or tricks that apply to a particular technology.
It can go either way, and I'm certain not trying to argue that quick fixes should never be replaced -- just that trade-offs should be considered.
This is something your hear in a lot of places. Often (not always) it seems to be spoken with regret. I think we should be quicker to celebrate than a problem has been solved (and seems to be staying solved!) without worrying so much about whether it was done "properly".
Indeed, I think the frequent success of temporary solutions should be seen as a challenge to the prevailing orthodoxy that software developers should be striving towards more discipline and process. Instead, we should be looking seriously at why quick fixes and cowboy coding work so well, and asking whether we can apply these more widely.
It's a tricky balance, though...
https://mitpress.mit.edu/sites/default/files/sicp/full-text/...
Fun is important, and it seems all too easy to lose sight of that.
It's a good set of questions to keep in mind, but I'm not sure it always leads to a feasible course of action.
What I like is working independently on a gnarly problem for some extended period of time. That explicitly includes spending the odd day "spinning my wheels" without being immediately being pushed to ask others for help -- because bumping my head against stuff while working alone is the way I like to learn stuff.
This way of working seems to be under fairly vigorous attack in favour of "everything needs a team", and I'm not quite sure how to work around that. Just pointing out that I'm getting things done does not seem to be sufficient.
However... skimming through some of those, they actually look like pretty typical "work on a team" positions (e.g. "...technical guidance and mentoring of Computer Technicians with focus on accurate completion of work orders and execution of standard operating procedures..."), not "this cupboard has spares, this cupboard has rations, see you in 6 months, good luck!".
Any hints for finding something that's closer to the second option?
These are both really great ideas, and have the advantage that they work for people who prefer to work through new stuff in private. Sometimes, organizations seem determined to combine learning/exploratory stuff with team-building exercises (A lot of Hackathon-type end up in this bucket, for instance), and to my mind that can end up severely limiting the amount of quiet experimentation that happens.
That's a good question, but having agreed that such debates don't contribute much, you've got two ways to go: either enforce a standard, or "live and let live" (perhaps supported by strong-ish module ownership). I think it's unfortunate that the "live and let live" option seems to have largely fallen by the wayside over the past few years.
I'm actually pretty certain this approach, with the TODO file in VC, would work fine at least up until 4-6 developers, as long as everyone hits a basic level of competence -- but in practice, someone always suggests a more structured tool well before that point.
A big one is that managers are de facto judged by the size of their team (and, for more senior ones, the size of the tree underneath them, too). It seems to be really, really hard to have middle management in an organisation without "maximise headcount" becoming an unofficial goal.
Edit: Employee happiness is an interesting one here. It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
Please do not use an existing networking framework (e.g., Twisted or asyncore for Python, ACE for C++, etc.) to implement the server.
...would be a massively positive signal to me as a candidate. Places that truly value "full stack" abilities like this seem to be hard to track down.
The more frustrating situation it needing to jump in and make a one-off fix to something that is at least notionally "modern". These can be just as impenetrable, but you have to hold your tongue much more (especially if some of the developers are still around), and there's generally a lot less kudos for sorting things out. Personal "favourite": debugging stuff that's virtually impossible to build locally "...because we've got this great CD pipeline".
What on earth do you mean by this? It sounds rather like advocating just doing the minimum you can, for the sake of harmony.
(More generally: I'm pretty firmly in the camp of "terse code tends to be easier to read and reason about", and don't want language designers nudging me to break expressions up and name intermediates).
I think most work is -- at the very least -- bearable given enough independence/autonomy. Programming can certainly be pretty joyful given a reasonably open-ended project and a quiet spot to sit. It's getting the autonomy that's the tricky bit.
The thing I find most helpful is to make sure that there are always several parts of the system that I'm actually working on. This means I've got a choice of what to work on today (autonomy!) and can somewhat context-switch my way around the awkward bits (which sometimes get less awkward after a few days on the back burner). Don't get carried away with this (spending all your mental cycles deciding what to do next won't help, either), but it's worth a try. It's one of the things that makes me love largish solo projects.
For the specific case of work ethic in the sense of committing deeply to projects you believe in, then I'd point you towards "The Soul of a New Machine".
But I'm sure others see it completely different.
For me, I think that a key difference might be one of "directness". That is, building things that directly relate to what the user experiences, rather than following processes which you have to trust will lead to the eventual creation of something enjoyable or valuable.
Paul Graham wrote something which, for me, does a pretty good job of capturing how things feel when you're working in this kind of way[1], and also explaining why there's an impedance mismatch between this and what larger organisations tend to be looking for.
It seems a sad thing to have to suppress.
Taking a break from a problem can be really valuable. Personally, I skew more "take a walk" than "table tennis", but having some indoor options for people who prefer those (or rainy days...) doesn't seem such a bad thing.
The one alternative that (some) code-review advocates seem willing to accept is XP-style full-time pair programming. But that leaves even less room for individuality and solo accomplishment.