< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #165 - May 8, 2022

If you are looking for work, check out this month's Who is hiring?, Who wants to be hired? and Freelancer? Seeking Freelancer? threads.

Here are the top threads of the week, happy reading!

Top comment by theirishgoodbuy

The way I look at it is: there are more tools in the toolbox than ever before. Which makes our judgement (the thing they really pay us for) even more important. Kubernetes, for example, is a specific solution to a specific problem. The solution is complex but so is the problem. If k8s give you the right trade-offs for your situation, then it’s not busy work.

Of course, there are plenty of project where judgement Is thrown out the window in favor of adding a buzzword to everyone’s resume. I’ve heard it called “promotion-based architecture”, as in you pick the technology most likely to get you promoted. (If that works, it says all sorts of not great things about your organization).

Regardless, I don’t think the availability of tools is the root problem. It’s and industry-wide lack of emphasis on identifying and understanding the problem first.

Top comment by c7DJTLrn

Not sure if games count as software but if they do - Factorio. I don't play much these days but I'm still utterly stunned how a relatively small, humble team of developers can build something so robust and performant. Granted, I've never really tried pushing the limits, but not once have I felt like the game is even breaking a sweat while processing thousands of machines, belts, and bots. It's a miracle to me.

Their devblogs are really nicely written and you can tell they are extremely passionate about getting things right. In my experience that's a rarity now.

And of course, it's a brilliantly addictive game.

Top comment by fleb

This sounds like burnout to me. I am in my mid-40s and used to have spells like this, but no more. I needed some kind of large change, back then, to get myself sorted out, but this could be pretty destructive because if I waited too long, the change I'd need wouldn't really be conducive to staying on whatever project I was on.

The key to not having to deal with this problem anymore, for me, was starting to proactively switch things around to break the routine of consecutive work-weeks. One of my tricks was to do some kind of mini-vacation every 6-8 weeks, go somewhere new, leave work behind for 3-4 days. Even smaller things like regular social events can work wonders - anything that breaks the weekly routine.

Back when I'd get myself into burnout periods the most effective way to recover enthusiasm was to pick up a new skill, work-related or not. I was in my mid-30s in the late aughts and not entirely sure I wanted to keep coding - so I signed myself up for an 18 month "executive MBA" program to find out if I might want to do something else, and instead came out of that with a whole new outlook on how and why to write code.

Then around 5 years later I started writing code on the side, for myself, to gradually improve over the long term, and this can be absolutely therapeutic.

Try to switch things around a little bit, do something new, see if that helps?

Top comment by vinay_ys

In most tech companies you can negotiate a lower number of days per week for lesser pay. In the last two decades I've been in the industry, I knew very junior people (early in their career) and very senior people doing 3-4 day workweek due to personal reasons in pretty much every company I worked in. It wasn't a big deal. Ability to take 3-6 month long unpaid breaks (sabbaticals), 4 weeks of PTOs, plus sick/carer leaves are quite standard in most good tech companies.

During Covid, many companies started doing rest/reset days every quarter that is basically a forced holiday for everyone together (no FOMO, no pressure to check emails, attend calls etc). Some companies have started to do rest/reset week every quarter! (because they think its necessary given their higher stress level work).

Getting time off isn't that hard. What is actually hard is getting high-quality work (where you get back as much as you give), satisfying work and a great team to do it with. Without great work and team, but have lot of PTO/perks etc it becomes very unsatisfying and not able to sustain interest.

I also see many companies screwing up by not investing in talent/skill development activities (not the typical corp L&D where they organise a workshop with some random person who seems very preachy and doesn't really practice). I wish they did this better and enabled people to manage their personal time better on their own.

Top comment by sithadmin

FWIW, a lot of US employers report your current employment status, role and salary to databases like Equifax's 'The Work Number' - and nearly any organization that subscribes can view this data. HR departments DO look at this info and occasionally spot-check it to catch moonlighting employees.

You can request your own data here: https://employees.theworknumber.com/

Top comment by somehnacct3757

You have no way of knowing that you would have done well in the manager role and gotten promoted to director like your peer. You claim to be more hard working and intelligent than him but who's to say what you view as hard working and intelligent are objectively true? Who's to say success in those roles is even a function of hard work or intelligence? Who's to say your peer didn't have some third skill relevant to managering and directoring that you lack in comparison? Maybe the thing that led to your peer's promotion was his boss's partner meeting his partner at a holiday party which put him on the radar. Who the heck knows.

If a man in line behind you at the convenience store buys a lottery ticket and wins a million dollars, do you kick yourself for not buying that ticket when it was your turn in line? Life is chaos; pretending things like this are in your control is useless. Punishing yourself for not knowing what you didn't know in the past is cruel.

Your misery comes from your own self-imprisonement. Happiness will not come from a time machine. Rather you should work on keeping your ego out of the driver's seat. A therapist might help, to teach you frameworks around catastrophization. Eastern philosophy has a lot of answers for dealing with ego as well. Alan Watts' The Book is a good way to experiment on that path.

Forget the past and focus on the present. If you don't like the present, focus on the future.

Top comment by triska

One of the most interesting applications of Prolog I have seen in the recent past is the formalization of dose-escalation trial designs that occur in clinical oncology. In particular, David C. Norris has implemented a Prolog formulation of the cumulative cohort design (CCD) as part of his precautionary package:

https://github.com/dcnorris/precautionary/blob/main/exec/pro...

This Prolog program can be used to exhaustively enumerate all possible arising cases, and also to complete partially given trials. In addition to the specific usage mode of telling the clinician what action to perform next after a sequence of events has occurred, it is also possible to ask interesting questions about the trial design as a whole, such as whether specific cases can arise at all, or whether a specific instance was performed according to the protocol. In this sense, the formulation truly serves as an executable specification of trial designs that are otherwise stated only comparatively informally in the medical literature, and may even be subject to divergent interpretations. The formulation uses Scryer Prolog and the latest Prolog language constructs (such as if_/3 and CLP(ℤ) constraints) to achieve a short and very general description. Such declarative specifications may help considerably to improve safety and efficiency of clinical trials, by making all steps and outcomes amenable to analysis and comparison.

Theorem provers and reasoning engines are also often implemented in Prolog. A recent example is solidarity by Jos De Roo:

https://github.com/josd/solidarity

Prolog is also frequently used for prototyping interpreters. For example, Adrián Arroyo Calle is working on a MIPS simulator written in Prolog:

https://github.com/aarroyoc/mipsie

Simon Forman has implemented a Prolog interpreter of Joy in which, remarkably, the declarative description also serves as a type inferencer and type checker:

https://git.sr.ht/~sforman/Thun/tree/master/item/source/thun...

Porting this code to Scryer Prolog could be an interesting project if it appeals to you. There is already an issue for it and pertaining discussion:

https://github.com/mthom/scryer-prolog/issues/388

Top comment by amalcon

I don't think it's possible to learn macroeconomics "properly", in the sense that one can learn e.g. quantum physics "properly". I pick quantum physics because not every expert agrees on some of the tail end of theoretical things, but there's broad agreement on the main parts of it. Those main parts are more than the average person will ever need to use.

This is not remotely true with respect to macroeconomics. It's absolutely routine that you can find even two orthodox economists (or hedge fund managers, or other practical folks if you prefer) who look at the same situation and predict incompatible outcomes. You don't even need to go down the various heterodox rabbit holes; people ostensibly operating from the same theory routinely make opposed predictions.

It's still worth learning some of the vocabulary, because it is useful for understanding what people are talking about. Of course learning is also gratifying for its own sake, and don't let anyone dissuade you if that's what you're up to. Still, I don't think it makes sense to learn macroeconomics on an expert level for a practical purpose. I don't think it's possible to define what an "expert level" even is.

Top comment by taylodl

I remember when Stroustrup's C++ came out in 1986. I used to be able to cite the Annotated Reference Manual (ARM) by chapter and verse. But if I were a young programmer in 2022 and looking at learning either C++ or Rust I'd choose Rust in a heartbeat.

Why?

Many reasons. For starters, C++ is 40 years old at this point and embodies software engineering practices from the late 70's to early 80's (for you young folks, structured programming was the new hotness in the 70's!) C++ was also designed to take advantage of C's tooling, or lack thereof. C had incredibly simplistic dependency management. It worked well for the time since there were very few external dependencies, almost the entirety of the codebase was hand-built by the entity creating the software. There were very few libraries outside of the standard libraries.

C++ has an object model making it difficult to use and extend objects from different code bases/libraries. Never mind the inheritance patterns leading to lots of confusion. Just remember, Java and later C# were created to address these issues with C++. They were both touted to be better versions of C++ (which was true in the application development space where a GC could be tolerated)

Finally, the C++ type system is barely a type system as we understand them today. That's just history - C++ reflects our best thinking from the 70's and the modern type systems started emerging in the 80's. The simplicity makes some things unduly burdensome to implement.

Don't get me wrong - I've programmed in C++ for decades and I like it, warts and all. But I'm also practical and I recognize its days are numbered. Will C++ be around in 20-30 years? Absolutely! But so is Cobol, and would you start a major project today using Cobol? No. You can see we're shifting from C++ to Rust. C++ is the past and the lion's share of the present but Rust is gaining on the present and is the future. If I did't know either Rust or C++ in 2022 then I would focus my efforts on learning Rust.

Top comment by d--b

In my opinion, you shouldn’t try and take a position of mentor in the field if you don’t have the experience/authority to do so. You’ll just misguide her.

There are things i can think of that you may try:

1. Try and do something techy yourself. Getting your own hands dirty will give you much better insights into what she’s getting into. Something that’s useful to you. I don’t know what you’re into, but if you have a hobby, it’s usually easy to find an idea for a tool that will help with that hobby. Just make sure you don’t try and take her place or something.

2. Probably better: Ask HER, if she could make something useful to you, or even better for your whole family / community. You may go for something a little more complicated, cause she’ll have more time to devote to this. IoT projects are very rewarding and touch a lot of aspect of tech. Home automation projects are great, like connected lightbulbs that respond to voice or if you have emails. Small games like wordle are cool too. Or things like community websites. When I was 18 (22 years ago!), I built a message board for me and my friends. It was really fun and then i could customize it for things we liked to do, like rating movies, and plan holidays. We used it for years, and only stopped when the ISP stopped supported the backend tech I was using.

In any case, the sooner she starts the better off she’ll be. The first thing is to pick up anything: a book or a tutorial online, and give it a shot.

Good luck, and have fun!!