I’m spending months coding the old way

I've had other people look askanse at me, but on greenfield work I tend to start with pen and graph paper. I'm not even writing pseudocode, but diagramming a loose graph with potential functions or classes and arrows interconnecting them. Obviously this can be taken too far, full waterfall planning will be a different exercise in frustration.

I find spending a few hours planning out ahead of time before opening an editor saves me tons of time actually coding. I've never had a project even loosely resemble the paper diagram, but the exercise of thinking through the general structure ahead of time makes me way more productive when it comes time to start writing code. I've tried diagramming and scaffolding in my editor, but then I end up actually writing code instead of big picture diagramming. Writing it on paper where I know I'll have to retype everything anyway removes the distractions of what method to use or what to name a variable.

The few times I've vibe-coded something this was super helpful, since then I can give much more concrete and focused prompts.

All this to say that it is extremely useful to have the program and the problem space in your head and to be able to reason about it before hand. It makes it clearer what you expect and easier to catch when something unexpected happens.

As a sort of an adjacent point, I worked through a book that is used on a course often called "from nand to Tetris". It is probably the best thing I've done, in terms of understanding how computers, assemblers and compilers work

https://amzn.eu/d/07pszOEy

Today I program 6502/7 asm for my Atari to help me unwind and it grounds me and gives me joy, while in my day job I'm easily 10 levels of abstractions higher.

But a few hours (or days) in, I forget what the problem was. A part of my brain wakes up. I start thinking about what I'm passing around, I start recognizing the types from the context and names...

It's just a different way of thinking.

I recognized the same feeling after vibe coding for too long and taking back the steering wheel. I decided I'd never let go again.

https://www.gnu.org/fun/jokes/ed-msg.html

My first job out of university I was taught how to use a line editor in IBM UniData. It was interesting getting used to writing code that way.

But it was an amazing day when I discovered that the "program table" was just a directory on the server I could mount over FTP and use Notepad++.

If you're prepared to forgo some portability and pick an architecture assembly opens up a lot if options. Things like coroutines, automatic SIMD become easier to implement. It's also got amazing zero cost C FFI (and I'm only half joking). Linux kernel booting into a minimal STC Forth is a lot of fun.

Not to mention you can run your code on android without SDK or NDK over ADB (in the case of aarch64).

One of the continuous battles I kept loosing when introducing an assembly language undergraduate course. Other higher up colleages and deans would say... too hard... nobody uses that anymore... and shut the course down. But I would always sneak it into other courses I taught, systems programming, computer languages, computer architecture. But I've always felt there was a hole in my student's understanding of computers.

I grew up in a time when assembly language was a part of the cariculum. It helped bridge the gap between higher level languages like C/C++ ...etc. Also why certain language features exist. Also how many language constructs work. Also more importantly, as pointed out by the two posters above, it gives you a way to think about the CPU one asm line at a time what is going on the CPU ecosystem. That is fantastic training!

Even though I kept loosing the assembly language course battles, I hope I planted enough seeds in students that they will take it up on their own at some point. Everyone should at least learn to program in one assembly language.

As someone that used to write C and Assembly programs on a sheet of paper for university exams, I chuckled a bit. I finished university in post-soviet country twenty years ago or so and this was the norm. I used to hate it so much.

When I built my first guitar I had very few tools so I used what I had since I'm cheap ;) Then I bought better tools and it made my life a lot easier. But I got some lessons from the experience. Mostly though it was a pain that's solved by better tooling.

Spaces are sometimes mandatory sometimes not. Something I didn't even think might be confusing, for me it's like breathing.

I am currently working in Swift, with an LLM, on a fairly good-sized app, in Xcode, for a device that probably has a minimum of 64 GB of storage, and 8 GB of RAM.

I don’t really miss the good ol’ days, to be honest. I’m having a blast.

scaring people away w x86 cruft right out the gate is no good for anyone :-)

I'm pretty skeptical that using a line editor will have helped them learn. It probably helped them memorise their code but is that really learning? Dubious.

I hope if/when diffusion models get a little more traction down the line it'll put some new life into autocomplete(-adjacent) workflows. The virtually instantaneous responses of Inception's Mercury models [0] still feel a little like magic; all it's missing is the refinement and deep editor integration of Cursor.

On the subject of diffusion models, it's a shame there aren't any significant open-weight models out there, because it seems like such a perfect fit for local use.

[0] https://www.inceptionlabs.ai/

When I let an agent write too much of the structure, the code may work, but a week later every small change starts with "where did it put that?"

For me it was GW-BASIC and no editor as we know them today.

That was instant gratification, rapid development, no silly layers. It was pretty pure. It is what hooked me.

In a sense, agentic coding, has brought back the excitement to building software for me because I don’t have to wrangle all the crazy enterprise or other modern development considerations directly. There’s a closer connection between thought and result, which is what was the magic that captured my imagination.

Despite what some might say, there isn't a big moat between those who use LLMs for programming and those who don't. So if I ever truly need to use LLMs to survive, I'll just have to start paying for a subscription.

In the meantime, I'll be keeping my own skills sharp and see how that turns out in a few years. I'm afraid software quality is going to take a nosedive in the near future, it was already on a downward trend.

That's an interesting thing to include. I agree with this point in principle, but I've found that Claude, at least, duplicates logic FAR too often and needs nudging in the other direction.

I can't do it. If I let an LLM write code for me, that code is untouchable. I see it as a black box, that I will categorically refuse to open. If it works, I use it, but don't trust it. If it breaks, I get frustrated. The only way that works for me is me behind the driving wheel at all times and an LLM as an assistant that answers my questions. We either brainstorm something or it helps me express things I know in languages syntax. Somehow that step has always been a bit of a burden for me - I understood the concepts well, but expressing them in syntax was a bit of a difficulty.

The shark is being jumped.

Someone thought I was naive when I said my vibe coded internal web admin site met the security requirements without looking at a line of code.

I knew that because the requirements were that anyone who had access to the site could do anything on the site and the site was secured with Amazon Cognito credentials and the Lambda that served it had a least privileged role attached.

If either of those invariants were broken, Claude has found a major AWS vulnerability.

I’m very concerned about how the next generation of software engineers will pick up deep knowledge about this stuff, if at all.

I also expect a bunch of open source/open core projects to go closed source in the next few months.

Once upon a time we wrote code in assembly language. Then we moved to C or other compiled languages. Assembly programming remained a very useful but niche skill. You compile your code and trust the compiler. You can examine the compiler output and that is at times necessary, but that's not something most developers know how to do.

We may be looking at something similar. Most development work moving to the LLM abstraction level, with the skills being writing good prompts, managing the context window, agents, memories and so on. Some developers will be able to examine LLM generated code and spot problems there, but most will not have that skill.

I'm not sure how to feel about it. Since ChatGPT showed up and until a couple months ago, I was firmly skeptical of LLM programming. We had new models every few weeks and I felt like each new model is just a different twist on the same low quality slop output. But recently the models seem to have crossed some threshold where their capabilities really improved and I have now used Claude - still using it sparingly - to implement features in much less time than I'd need myself or to locate a bug based on just log output. I don't yet buy the "coding is solved" hype but we're at least looking at the biggest change to programming since the adoption of high-level programming languages.

Not trying to be rude but you either must not be a professional software engineer or your skill level isn't that high yet. You simply cannot always do things that teach you new skills or improve existing ones. In any sufficiently complex project, even the most novel ones, you'll do things you've done many times before.

Most folks do RC between jobs, either because they quit their job specifically to do RC or because they lost their job and then decide to apply. Other common ways are as part of a formal sabbatical (returning either to an industry job or to academia), as part of garden leave, or while on summer break (for college and grad students). We also get a fair number of freelancers/independent contractors (who stop doing their normal work during their batches), as well as some retirees.

Some folks use RC as a way to enter the industry (both new grads and folks switching careers), though the majority of people who attend have already worked professionally as programmers.

We've had people aged 12 to early 70s attend, though most Recursers are in their 20s, 30s, and 40s.

Unless you can swing a six week sabbatical and return to your current job

> coding the old way is good for you. i'm not convinced it's what gets you noticed.

You won’t go completely unnoticed if you’re good at your job but you can only be noticed from your deliverables, which is a slow process. You can buff up your presence by talking about it a lot, yes, but you won’t get 0 attention for hard work.

My ex business partner said “AI won’t take your job, but the person who uses it will”. I don’t agree. The person who isn’t reliant on AI is the one you should really be afraid of.

It's not though. It's fundamentally different because TurboTax will still work with clear deterministic algorithms. We need to see that the jump to AI is not a jump from hand written math to calculators. It's a jump from understanding how the math works to another world of depending on magic machines that spit out numbers that sort of work 90% of the time.

If we assume that there are 50 weeks per year, this gives us about 400-500 lines of code per week. Even at long average 65 chars per line, it goes not higher than 33K bytes per week. Your comment is about 1250 bytes long, if you write four such comments per day whole week, you would exceed that 33K bytes limit.

I find this amusing.

So only the old hands allowed from now on, or how are we going to provide these learning opportunities at scale for new developers?

Serious question.

That is exactly been the situation for years. Once graduated accountants are not doing maths. They are using software (Exel, Xero etc.). They do need to know some basic formulas eg. NPV.

What they need to know is the law, current business practices etc.

If that's true, then you likely used to produce slop for code. :-(

> I did things the old way for 25 years and my carpal tunnels are wearing out.

You wrote so much code as to wear out your carpal tunner? Are you sure it isn't the documentation and the online chatter with your peers? :-(

... anyway, I know it's corny to say, but - you should have, and shoudl now, improve the ergonomics of your setup. Play with things like the depth of your keyboard on your desk, the height of the chair and the desk, with/without chair handrests, keyboard angle, etc.

> Job one of everyone I mentor is to build Linux from scratch

"from scratch" can mean any number of things.

Maybe text that costs a LOT of tokens. Very, very verbose. I think if there are rules and on the internet, LLMs can eventually figure it out, so you have to make it expensive.

Another way would be to go offline. Never write it down, only talk about it at least 50 meters away from your phone. Transmitted through memory and whisper.

Though a lot of the time this is more an inefficiency of the documentation and Google rather than something only LLMs could do.

This can be set as far as 1h of being stuck. Can also be 5 minutes. But by default it is 30 seconds.

My inner kid was screaming "that's cheating!" :-D but on second thought it is a very cool feature for us busy adults, however it's sad the extremes that gamedevs have to go in order to appease the short-term mindless consumers of today's tik-toks.

But more seriously, where's the joy of generating long-standing memories of being stuck for a while on a puzzle that will make you remember that scene for 30 years? An iconic experience that separates this genre from just being an animated movie with more steps.

I couldn't imagine "Monkey Island II but every 30 seconds we push you forward". Gimme that monkey wrench.

TFA and this comment just made me have this thought about today's pace of consumption, work, and even gaming.

* Ask someone to come over and look

* Come back the next day, work on something else

* Add comment # KNOWN-ISSUE: ...., and move on and forget about it.

But year spent days on a bug at work before ha ha!

If anyone remembers middleschool mathematics this is the coding example of the teacher making you write out the equations in their longest form instead of shortcutting. It's done this way because it shows you your exact train of thought and where you went wrong. That sticks in your head. You understand the problem by understanding yourself. Giving up after twenty minutes instead of stopping, clearing your active cognitive load, and then coming back erases your ability to understand that train of thought.

For a comparison it's like being in first person view in a videogame, and the only thing you have is the ability to look behind you, versus being able to bring up a map that has an overhead view. In first person you're likely to lose where exactly you went to get where you are, while with the overhead view map you can orient your traveled route according to landmarks and distance.

But just today a bug was reported by a customer (we are still in testing not a production bug). I implemented this project myself from an empty git repo and an empty AWS account including 3 weeks of pre implementation discovery.

I reproduced the issue and through the problem at Claude with nothing but two pieces of information - the ID of the event showing the bug and the description.

It worked backwards looking at the event stream in the database, looking at the code that stored the event stream, looking at the code that generated the event stream (separate Lambda), looking at the actual config table and found the root cause in 3 minutes.

After looking at the code locally, it even looked at the cached artifacts of my build and verified that what was deployed was the same thing that I had locally (same lambda deployment version in AWS as my artifacts). I had it document the debug steps it took in an md file.

Why make life harder on myself? Even if it were something I was doing as a hobby, I have a wife who I want to spend time with, I’m a gym rat and I’m learning Spanish. Why would I waste 6 hours doing something that a computer could do for me in 5 minutes?

Assuming he has a day job and gets off at 6, he would be spending all of his off time chasing down a bug that he could be using doing something else.

This is exactly how you learn to create better abstractions and write clear code that future you will understand.

You mean the way that the majority of code is still written by professionals?

Why would you think that? The landscape is fast-moving. Prompting tricks and "AI skills" of yesterday are already dated and sometimes actively counterproductive. The explicit goal of the companies working on the tech is to lower the barriers to entry and make it easier to use, building harnesses and doing refinement that align LLMs to an intuitive mode of interaction.

Do you think they'll fail? Do you think we've plateaued in terms of what using a computer looks like and your learnings for wrangling the agents of this year will be relevant for whatever the new hotness is next year? It's a strong claim that demands similarly strong argument to support.

How? I just open multiple terminal panes, use git tree, and then basically it’s good old software dev practices. What am I missing?

It is hard indeed. I find it really quite exhausting.

Personally, I feel like I have always been a very competent programmer. I'm embracing the new way of working, but it seems like quite a different skillset. I somewhat believe that it will be relevant for a long time, because there is an incredibly large gap in outcomes between members of my team using AI. I've had good results so far, but I'm keen to improve.

For the good stuff, there’s no alternative but to know and to have taste. Llms change nothing.

Citation needed.