deangiberson

https://probplanner.com/ - I never had the time to dedicate to building a Monte Carlo simulator for project estimates. It was always something I just couldn't justify given my short commute. I used this project to teach myself how to use Claude Code and Codex over last summer.

I've done a lot of little things in Emacs since. Just minor things to improve my workflows or build up Chief of Staff type information flows.

Funny, I started vibing this (https://github.com/deangiberson/emacs-mux) yesterday on the train after playing with cmux for the day and thinking to myself there was nothing that emacs couldn't accomplish.

The repo doesn't quite work yet. Many sharp corners. But the basic idea is there.

pama, I'd be interested in hearing more about how you are using emacs for multiplexing. I'm trying to build up tooling for myself based around file and input workflows and I /really/ don't want to write a text editor and would prefer to stick with emacs.

I have time to code up little tools for myself and my team. I can now automate simple things quickly to improve workflow, like gathering all the modified tickets in the past 24 hours and writing them out in our daily sprint document (it's the process they want so I go with it). Am I directly contributing to the critical path code, no, but I'm able to understand more quickly. I'm a Sr SDM and have been divorced from daily code for several year, now I'm able to get a broad view of things more quickly. Even just the act of finding dependent packages removes a little friction which means I'm less likely to let it become a road hump.

Edge(FluentBit -> Logs -> cron(compress -> encrypt)) -> Cloud(S3 -> Trigger -> Lambda decrypt -> S3 -> Trigger -> Lambda decompress -> S3 > Trigger -> Lambda to CloudWatch)

I have a system that runs on edge services and captures everything to logs through FluentBit. Then there's a cron job that compresses, encrypts, and tries to send the logs to device specific S3 buckets. If the on device logs get too big they start dropping old logs first, with a heuristic for certain logs being more/less important. When devices reconnect to the cloud they start pushing logs as quickly as they can, the cloud infra backfills metrics as they arrive.

Once in S3, triggers start a series of lambdas to decrypt, decompress, analysis. Works well, easy to reason about.

The backend can easily be swapped out for something else. The harder part is the log compress/encrypt/rotate. It's important that you don't treat all logs exactly the same. Some are much more important and should be preserved over others.

Whatever the team I'm working with is currently using. Chasing the most recent tool doesn't add value until you see a process problem that a new tool obviously fixes without breaking everything else.

Send out an I love My Little Ponies email to the whole organization. An old tradition.

I was diagnosed with ulcers at the age of 10, well before Warren's work. For 11 years I dealt with constant pain and people telling me I just needed to learn how to relax. At the age of 21, at my next twice-yearly doctor appointment, my doctor asked me if I had heard about this news. I had, and I was willing to try it out as an experimental treatment. Eight weeks later I was cured. No pain. No after effects. Robin Warren impacted my life in a very real way.

What do you value more right now? Time or money?

"Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience."

Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.

Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.

I have a 1yr old System76 Galago UltraPro. I like it, works well, fairly quiet. Purchasing experience was good, even with importing to Canada. My two problems are 1) it will occasionally (once every 2 months) experience a power loss and reset the laptop. No clue as to what's happening, so infrequent that I don't care to look too deep, 2) the wrist rest finish is rubbing off in the corners, looks dirty, but it's just the black plastic showing through.

I'd focus on a repeating theme in your post, "and now they". This suggests that you already see a division between the management of the company and yourself. You haven't been part of the decision making process and feel that all possible angles have been locked out by an outside agency. How much feedback have you given to the company management that you would be interested in those positions before they where "taken" from you? Have you done a gap analysis between your current operating skill set and the expectations for those position? What skills have you tried to improve outside of "developer" recently that would show you are trying to expand your role?

You need to get past the "been told", and start communicating what you want to achieve. It might be too late at this company, but I would bet not, just because these roles are already filled doesn't mean they will stay filled, or that tasks won't outgrow the current holder. Think ahead, and aim for a goal, communicate with every means you have that your ready for that goal.

"Fortune favors the prepared mind." - Louis Pasteur

They can't explain what they've learned, because SICP covers so much ground. The best way I can explain is by negative examples. SICP is not:

- A learn X in 7 days book

- A technique driven solution book (cookbook)

- A quick overview of the new hotness library/language/api/framework

- A list of all the functions that you should know

- A reprinting of the half complete wiki documentation of a weekend github toy

- A one off read that you dump in the recycle bin

SICP gives grounding to some of the core problems in computer science. I've returned to it several times, and I always learn something from what I've missed before. Understanding how functions/closures/namespaces/objects all interrelate, how to think in recursion, building higher order programs from pieces, it even covers simple examples of VMs. It's a very strong entry text that has stood the test of time, and is still providing value. Few texts in comp-sci can say the same. SICP does a good job of connecting the theory of comp-sci with a real language without overwhelming the student with absurd language syntax problems.

When any one asks me to recommend a computer book I recommend SICP. Best of all no one has to take my word for it, the book is free. https://mitpress.mit.edu/sicp/ go read it and form an opinion.

Who is SICP not for? If you are at a high level with programming with multiple languages under your belt, most of this would seem like a refresher. If you really "know" VMs then this is going to very low level stuff. If you want a quick read to learn the syntax for scheme this is not the book for you.

I think these are two overlapping non-linear functions, the intersection of the two is a minima.

"Many eyes" worked for a while but the benefits were lost as scale increased. You are saying that we need to focus on reducing code size. This other extreme is many small unrelated pieces of small functionality, which also breaks down. You would just have a bunch of small programs, some of which are ignored. The complexity remains constant.

Software inspection has shown to have good benefits, this is the heart of "many eyes", the trick is getting coverage. "Many eyes" worked when applied against small enough problems for self organizing groups. As you hint when you say "Modern code is too voluminous for there to be enough eyes to keep Raymond's theory working in practice." Isn't this a management issue? A problem of getting enough people to look into the dark corners and communicate the results?

I was a game developer for various AAA studios for many years and did many, many interviews for new hires. The number one thing that companies will look for is knowledge (you will be tested on this) the next is drive (you have to show that the company should take a chance on you). These things are no different than any other job.

Luckily there is a very simple thing you can do to hone the first and show the second. Make a game. Don't piddle around with an engine, don't read and talk about how you could do this and that if you were given a chance. Make a game. Make it small and completable. There is not a single thing stopping you from just making a game.

Find a genre you like and make a clone, then extend one area with a new idea. Or a clone that show you understand a specific technical area. Or create a mod for an existing game, hack new functionality into Minecraft, or change a control scheme in Half-Life. Just make something you can show, then show it.

A point though, you will find it easier if you pick an area to specialize in. Saying you want to get into the games industry is like saying you want to play in a band. What instrument do you play?

Most game studios don't hire many generalists without experience. So pick one area that you are willing to work at for 3-5 years and double-down. Then find a way to show 1) you've done your homework at a base level 2) are willing to sit-down and do the work.

Sometimes not continuing is the correct way to finish a project. Only keep working on the gems. Fail early, fail fast, fail cheap.

+1 for strong editing features. All the fancy stuff came after Emacs became an OS for editing text. Nail that, the rest follows.

And here I'm going to point to Bret's later writing, http://worrydream.com/#!/LearnableProgramming. It's not about the sliders it's about the understanding. A good example is the first large loop setting up the texture.

    for ( var i = 1; i < 16; i++) {
        var br = 255 - ((Math.random() * 96) | 0);
        for ( var y = 0; y < 16 * 3; y++) {
            for ( var x = 0; x < 16; x++) {

                ...

            }
        }
    }

My interpretation of Bret's idea is that it would be better to have the ability to highlight the section of the texture being written by each section of the loop. It's not the sliders & live editing that are most important it's about linking abstract control into meaning within the learner.