< Back to the archive

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

Issue #315 - March 23, 2025

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

Top comment by kaikai

I’ve been homeless and am now an employed engineer, so I know it’s possible to make the leap. You can’t make it in one go, though.

Get a better job, that can get you stable housing. I don’t know the job market in your area, but try looking for temp agencies. They will do a basic interview and help you find something that uses your existing skills. Until you get stable housing and your basic needs met, focus on what you can do with the skills you have now.

Seconding what others said about going to the library. In my community they serve almost as social workers, and have lists of places like food banks that can help you until you have better employment. Your county will also have resources for you; you can get on the waiting list for housing vouchers (they’re years long, but just in case), get food stamps, get leads for programs local to you.

Yes, it’s possible to end up with a tech job. There’s a big gap between where you are now and there, though, and having stability in the short term will help you get there.

Top comment by SeanAnderson

A little bit on TwitchTV, a little bit on Discord, and a little on Reddit, but, honestly, I feel pretty lonely on the Internet these days.

I've been on Reddit for over 15 years and yeah, it feels quite different than it did early on. I can't really stand browsing r/all or r/popular at all.

I miss the days of having 255 friends on AIM, trout slaps on well-populated mIRC channels, and never-ending threads on niche Ultimate Bulletin Board forums.

Top comment by seoulbigchris

A long time ago, a colleague and I visited a supplier in another state. While we were waiting alone in a conference room, we noticed an unusual looking note taking device at the front of the room. It was a very large easel that looked like a white board, with a tray of markers and an eraser. But it was clearly electronic because it had stuff attached to the top and bottom, some buttons, and was plugged in. We walked up to the easel, drew a large circle on it, and pressed what looked like a COPY button, curious how it was going to perform that task.

The machine whirred into action, scrolling the white board material (which turned out to be a flexible plastic-like film) over the top of the easel, and paying out fresh whiteboard up from the bottom. A perfect duplicate of our circle on paper spat out of a slot in the machine, akin to a FAX machine. As the scrolling came to a stop, it revealed a previously hidden drawing -- someone had drawn a large "X" in the middle of the page. I guess we weren't the only ones who were curious how the machine worked.

Top comment by ruuda

Woah, so much overcomplication in the comments!

If you want to run multiple applications, how about ... just running them? It sounds like you already do that, so what is the real problem that you are trying to solve?

If it's annoying to start them by hand one by one, you could use Foreman or Overmind to start them with a single command, and interleave their output in a terminal.

Top comment by 20after4

In every single domain they are systematically dismantling the USA and taking the spoils for themselves. We've been sold out. Start learning Chinese folks.

Top comment by hyperman1

I won't say yes or no, but here is my experience:

Once you know a few programming languages, learning an extra is really easy. And COBOL is among the more easy.

It is good to start with a reasonably designed mainstream language like Python, Java, C#, Go,... and learn to think like a programmer. Then pick a few weirdos like lisp, prolog, haskell, and learn what languages can provide if stretched. COBOL, Basic, PHP,... are today less well designed language that will teach you bad habits. As a first language, you'll have to unlearn things to grow.

Cobol programmers tend to be less paid and work slowly with gnarly code bases. By definition, you work for businesses that are bureaucratic and slow in changing anything. Your colleagues will be near pension age. Do you want this company culture?

You will have work forca long time, of course.

Users already know you'll answer that lots of their questions are impossible. It's easy to say no to them when they e.g. request a strange UI change.

Being a (human) translator between cobol and the rest of the company is a nice path to architect. It's rare to find a programmer talking to both sides of the IT world.

Cobol itself isn't the biggest problem. Even the mainframe isn't. But everything else will be bespoke to the company, underdocumented, hard to learn. That may include the text editor you use.

Top comment by rasmusab

Pure python scripts, maybe using the #%%-convention (https://code.visualstudio.com/docs/python/jupyter-support-py...) so you get the best of both notebooks and scripts, in a right-sized instance/container/machine. And if you need to run jobs in parallel, then orchestrate using make, like so: https://www.sumsar.net/blog/makefile-recipe-python-data-pipe...

Top comment by tmtvl

Losing good habits and forming bad ones is easier than losing bad habits and forming good ones, so I am very polite when I interact with AI. Wouldn't want to slip up and be impolite when chatting with normal humans.

Top comment by nottorp

What do the experts in learning say? Preferably some that don't work for the LLM peddlers.

In my non expert opinion, you learn a lot from at least two things that using a LLM short circuits:

1. Repetition. When you've initialized a bunch of UI controls 100 times, it's safe to let the machine write that for you, take a look and correct what it hallucinated. When you've only done it twice, you'll miss the hallucinations.

2. Correcting your own mistakes. Quality time with the debugger imprints a lot of knowledge about how things really work. You can do said quality time correcting LLM generated code as well, but (see below) it will take longer because as a junior you don't know what you wanted the code to do, while if it's your own you have at least that to start on.

Management types are extatic about LLMs because they think they'll save development time. And they do save some, but after you spend the time to learn yourself what you're asking them to do.

Top comment by t-writescode

APIs are just building blocks and blobs of single-ish responsibility. It's good to ask lots of different questions to understand the actual question being asked, what the desired capabilities of the thing being asked are, etc.

From there, you should be able to start laying out the different components and how they interact.

Edit: here's some areas of consideration when designing a system:

  * what does this thing do?
  * what are the expected inputs and outputs of the whole system?
  * what operations are we wanting to be able to perform against it?
  * how frequently will each of these operations be done?
  * how quickly do we want a response from this whole system?
  * what different sorts of integrations do we expect for this system? Any?
  * how often do we expect the system to change?
  * where do we expect to expand the system the most in the future? What will that look like?
I'm sure others will have many, many more things to add