Maybe I am just misunderstanding. I probably am; seems like it happens more and more often these days
But.. I hate this. I hate the idea of learning to manage the machine's context to do work. This reads like a lecture in an MBA class about managing certain types of engineers, not like an engineering doc.
Never have I wanted to manage people. And never have I even considered my job would be to find the optimum path to the machine writing my code.
Maybe firmware is special (I write firmware)... I doubt it. We have a cursor subscription and are expected to use it on production codebases. Business leaders are pushing it HARD. To be a leader in my job, I don't need to know algorithms, design patterns, C, make, how to debug, how to work with memory mapped io, what wear leveling is, etc.. I need to know 'compaction' and 'context engineering'
I feel like a ship corker inspecting a riveted hull
Guess it boils down to personality, but I personally love it. I got into coding later in life, and coming from a career that involved reading and writing voluminous amounts of text in English. I got into programming because I wanted to build web applications, not out of any love for the process of programming in and of itself. The less I have to think and write in code, the better. Much happier to be reading it and reviewing it than writing it myself.
No ones like programming that much. That's like saying someone love speaking English. You have an idea and you express it. Sometimes there's additional complexity that got in the way (initializing the library, memory cleanup,...), but I put those at the same level as proper greetings in a formal letter.
It also helps starting small, get something useful done and iterate by adding more features overtime (or keeping it small).
> No ones like programming that much. That's like saying someone love speaking English. You have an idea and you express it.
I can assure you both kinds of people exist. Expressing ideas as words or code is not a one-way flow if you care enough to slow down and look closely. Words/clauses and data structures/algorithms exert their own pull on ideas and can make you think about associated and analogous ideas, alternative ways you could express your solution, whether it is even worth solving explicitly and independently of a more general problem, etc.
IMO, that’s a sign of overthinking (and one thing I try hard to not get caught in). My process is usually:
- What am I trying to do?
- What data do I have available?
- Where do they come from?
- What operations can I use?
- What’s the final state/output?
Then it’s a matter of shifting into the formal space, building and linking stuff.
What I did observe is a lot of people hate formalizing their thoughts. Instead they prefer tweaking stuff until something kinda works and they can go on to the next ticket/todo item. There’s no holistic view about the system. And they hate the 5 why’s. Something like:
- Why is the app displaying “something went wrong” when I submit the form?
- Why is the response is an error when the request is valid?
- Why is the data is persisted when the handler is failing and giving a stack trace in the log?
- Why is it complaining about missing configuration for Firebase?
- …
Ignorance is te default state of programming effort. But a lot of people have great difficulty to say I don’t know AND to go find the answer they lack.
None of this is excluded by my statement. And arguably someone else can draw a line in the sand and say most of this is overthinking somehow and you should let the machine worry about it.
I would love to let the computer do the investigative work for me, but I have to double check it, and there's not much mental energy and time saved (if you care about work quality). When I use `pgrep` to check if a process is running, I don't have to inspect the kernel memory to see if it's really there.
It's very much faster, cognitively, to just understand the project and master the tooling. Then it just becomes routine, like playing a short piano piece for the 100th time.
I've started to use agents on some very low-level code, and have middling results. For pure algorithmic stuff, it works great. But I asked it to write me some arm64 assembly and it failed miserably. It couldn't keep track of which registers were which.
Honestly - if it's such a good technique it should be built into the tool itself. I think just waiting for the tools to mature a bit will mean you can ignore a lot of the "just do xyz" crap.
It's not at senior engineer level until it asks relevant questions about lacking context instead of blindly trying to solve problems IMO.
But.. I hate this. I hate the idea of learning to manage the machine's context to do work. This reads like a lecture in an MBA class about managing certain types of engineers, not like an engineering doc.
Never have I wanted to manage people. And never have I even considered my job would be to find the optimum path to the machine writing my code.
Maybe firmware is special (I write firmware)... I doubt it. We have a cursor subscription and are expected to use it on production codebases. Business leaders are pushing it HARD. To be a leader in my job, I don't need to know algorithms, design patterns, C, make, how to debug, how to work with memory mapped io, what wear leveling is, etc.. I need to know 'compaction' and 'context engineering'
I feel like a ship corker inspecting a riveted hull