- I only find it to be painful when done for the corporate world... when I go home, even after 7 hours at the office, I find it therapeutic to push to main, not have a CI, not write tests, test in production, commit with one-liners like I'm asking someone if they want a beer, and overall just code any random idea that crosses my mind... even more so now with AI, because now I can get my ideas out there faster, and believe me, this is serious crapware, but who cares? I don't...
- I work at a company where our production system WAS like this for a LOOONG time. No development environment, no tests, no documentation, QA was the end users, etc...
I have done a lot of work to improve the CI/CD, get them a development environment, teach some best-practices, get testing set up, reduce bus factor, all the modernization stuff. Oh, and get them a version control system (that helped a bit).
But man, what a rush it was when the system would go down at 11PM on a Sunday, I got to RDP onto the production machine and modify the production code ON THE MACHINE with a one-line fix and... CTRL+S was the production deployment strategy.
I watched one outage occur in real time when a coworker was showing me something on the production machine and CLICK+DRAGGED a live application directory into another one by mistake. Another outage occurred because someone stupid (me) destroyed the inetpub folder (all the IIS configurations for 95 applications). Cold sweats for an hour at 3AM thinking "this one is reallllly bad" before finding the backup.
I always imagined the tech team as these scrappy fellas running this extremely complex steampunk Rube Goldberg machine that was about to blow... I walked in and they just handed me a nailgun and said "GET TO WORK THIS OL' GAL IS ABOUT TO RUN OFF THE RAILS".
It was the wild west and part of me really misses that (not enough to go back though).
- Becauuuuseeeeee ...at home you can be "The Duct Tape Programmer" - https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
:-))
- > to push to main, not have a CI, not write tests, test in production, commit with one-liners like I'm asking someone if they want a beer
All the start-ups and SMEs I've worked at were about as rigorous as that. Maybe I've just been unlucky (or lucky, depending on where you come from).
- Programming doesn't cause me pain or feel like work. I build projects in my free time because I enjoy solving problems.
One thing I love about programming is that it forces me to understand ideas at a much deeper level than simply reading about them. Writing code requires both step by step reasoning and high-level abstraction. That combination often leads to better solutions and a clearer understanding of the problem.
I often ask myself, "Would I still do this if I weren't getting paid?" The answer is usually yes. That's why many of my projects are completely free, with no ads or subscriptions.
- Aside from the human side of it which is often nothing to do with programming itself, I'd say anything that is captivating is only so because its agonizing. If you have a problem to solve and instantly know the solution, there was no problem, just manual labour left not done (using that in the most technical sense). Solving problems is captivating, but it has to be hard or there'd be no problem at all.
- Yea solving hard problems can be quite enjoyable, but can easily become a burden on your mind/body over time. When you're clearly making progress, then everything feels wonderful even if it's challenging. But when you're stuck, when your code/model isn't working as designed, if there is a clear gap between your current state of understanding and the amount required to solve the problem effectively, then you can fall quickly into despair. It's made worse when you see others doing similar work to what you do, but being far more successful at it. And made even worse, when you tie parts of your identity to the problem you're trying to solve, and the code you write. But that's the nature of what you're trying to do, so it isn't all bad.
- I think what is agonizing is either the process imposed by the company or the architecture you are working with. Both can lead to immense frustration. When you have good architecture and a good development process, things become much less frustrating. I wanted to add one more thing: if you work on any idea you don't like, it doesn't matter the language, the platform, the architecture or the process. In the end you will feel the pain and frustration.
- This is one of my favorite quotes from Brooks:
Was this AI paraphrased? From the article:"In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment."
Same meaning, different wording."In practice, real authority comes not from titles but from influence built through consistently delivering results."Full book: https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythic...
- > Your goals are set by others; information and resources are provided by others. The programmer rarely controls his working conditions, sometimes not even his objectives. In management terms, "one's authority is not commensurate with his responsibility."
This is the real reason hackers start start ups.
- Relevant:
Self-Determination Theory - https://en.wikipedia.org/wiki/Self-determination_theory
Why We Do What We Do: Understanding Self-Motivation by Edward Deci - https://thorprojects.com/2020/05/04/book-review-why-we-do-wh...
Over-Justification Effect - https://en.wikipedia.org/wiki/Overjustification_effect
Companies by emphasizing only on "extrinsic motivation" without understanding what drives a person, effectively kill "intrinsic motivation" and hence transform what was once enjoyable into a detestable chore.
- The only things I find agonizing about programming:
1. unrealistic time frames and expectations from non-technical managers, and
2. leetcode
Everything else is awesome.
- 3. "Best Practices" having changed every time I go back to the frontend
- We should just call it "current practices", there is very little best in frontend.
- Nah, I have another one: Being confronted with my own stupidity and my own limits in mental capacity. The shocking thing is that this never goes away, even after decades of practice.
- Spoiler alert: this happens to literally everyone in every field and profession every single day.
- You must be careful not to let this become a self-defeating attitude.
Stop comparing with others and only focus on improving on your prior self. As long as you are making progress it does not matter how small each quantum is or how slow.
Concepts like "smart"/"stupid" etc. are relative (assuming there are no obvious biological causes) and are applicable only in specific domains. Each person can be associated with a "Radar Chart" (https://en.wikipedia.org/wiki/Radar_chart) of domain expertises (one spoke per domain) where it can be seen that one is naturally "smarter"/"stupider" in some than others.
Drops of water falling, if they fall continuously, can bore through iron and stone - Chinese Proverb.
- Because you get to solve real problems people have. But you have to work with real people.
- One answer - Other People's Code
I know my code, I don't know your code. I don't know what you were thinking, why it's in the shape it's in. What assumptions you made that you might not have documented or who's documentation I have not found. Also, if you're the person who has to review it I have no idea what you'll accept which means I have to gamble wasting my time to make a PR on the off chance that you might not approve.
With my own code, all that goes away.
The other big one is yak shaving. Being forced to do things B, C, D, E, F before I can do the thing I wanted to do. I've lost projects to this where like say, some library has a bug, there's a fix in the new version, but the new version depends on newer things, and pulling those things in is not compatible with the project. I spent 30 to 60 - 120 minutes trying to get it to all work so I can get work, getting more and more pissed off, because this isn't what I planned to spend my time doing. And, I often fail and give up. Progress stopped on at least one personal project for ~4 years where once every 6 months or so I'd try to update dependencies and fail and never actually made any progress on the app.
Fortunately, this year, AI was able deal with it. It fixed the deps, removed most of them, and implemented most of the features on my TODO list from years ago.
- I never found programming agonizing.
- I mostly find programming fun, I’ve been doing it most of my life, but I will admit that engineering can be pretty agonizing. I enjoy the stuff, I enjoy the algorithmic stuff, and I enjoy implementing the math and algorithms, but that’s only about half of any programming job I have had.
I derive zero enjoyment from Kubernetes configs, or Terraform, or fucking around with log settings, or screwing around with all the knobs for Kafka. That stuff is agonizing.
- Yeah - those are two very different roles and are separate job functions at a lot of places (depending on org size). I do both at my company.
I've never had that specific heads-down "programming" role where I can just read specs and write PRs all day, it's always been full-stack for me - which I personally enjoy... But the config / plumbing has always felt like a bit of drudgery.
At the end of the day that feels like the stuff that we do IN ORDER TO write code, so it doesn't really feel like the main event — so to speak.
- > I derive zero enjoyment from Kubernetes configs, or Terraform, or fucking around with log settings, or screwing around with all the knobs for Kafka. That stuff is agonizing.
The click for me was thinking in terms of outcomes and system dynamics. So I make sure to get a good understanding of the final state. Tweaking without a goal is just playing around, or joyless work if you do not enjoy the process.
- I suppose.
I guess programming to me was always an excuse to do math, not necessarily to build products.
- For me it's the exact opposite. I don't like math. I have very little intuition for it. Programming is not math for me even though people try to tell me that it is.
Programming is my way to create something. It's like drawing or woodworking. It is creative and logical. That's why I don't mind or even like sysadmin stuff. But I know a lot of coworkers that don't like ops and in my company you don't have to do that. We have teams for that.
- I've never really been a math person, either, which is why I thought I was going to hate discrete math in college. I mean, it wasn't always the easiest thing ever, but it was a lot more intuitive to me than continuous math. And that's all programming is, materialized discrete math.
- I like math. I’ve done engineering in college which included a fair share of it and pursue it for fun. Programming is also not math for me.
It’s formal notation where you’re manipulating things encoded as numbers. Just like music sheets are notation for sound encoded as some symbols. Yes, there is math involved (because numbers) but there’s often a more concrete reason for such manipulation.
It’s not so different than drafting a technical drawing.
- How do you know what you built is good? That was the pivot for me - I defined it for myself as it’s something that makes a positive contribution to my users.
- I take it you aren't programming business CRUD apps? I almost never have to do any math. It would be a delight if I did.
- I certainly have done my time with writing CRUD apps, but for the last decade or so, I've primarily focused on distributed systems stuff (usually involving Kafka or ZeroMQ or something), which is a bit more architecturey and I occasionally get to do some fun concurrency theory.
But when doing the more boring CRUD stuff I historically have gotten my math kicks out of playing with functional languages. I got into Haskell pretty early because I liked the idea that the type system felt pretty mathy.
- I love this comment. I never looked at it that way before. I wasn't able to articulate it but "an excuse to do math" is perfect. This resonates with me.
- Yeah same. I've been doing this for fun since I was like 9 years old. 30 years later it's still fun.
- To me frustration and excitement are related.
I've never punched the air after fixing some bug that I didn't at some point earlier get extremely frustrated at its intractability.
- Never?
Never some intractable bug, that didn't seem to have any relation to the source code you're reading?
- I rarely had them and if I did I enjoyed the hunt. I enjoy tracing through all the layers.
- You must not talk to other developers ;)
But seriously, sometimes its not the code, it's the human factor that's painful, other times, well it's JavaScript.
- Or at least the culture around JavaScript .
I love writing JavaScript. I like React well enough. I'm not sold on NodeJS, though I'll accept that its struggles are no different than any other package manager.
I just wish the whole thing would stand still for a minute. It's seriously exhausting to keep up with all of the deprecations, rewrites, new "best" frameworks, etc.
- How is Node a package manager?
- Fair. NPM is the part I actually distrust.
That said, I'm not sure it's necessary to make a distinction. I can't imagine many teams are using NodeJS (particularly with React or the like) without buying into the package ecosystem.
- [dead]
- Through words and patterns you can change the operation of the machine, and thus alter the physical world. Your programs are wizardry! The part that sucks is trying to make magic happen within an organization run by boring accounting people. The only room for magic is begrudging.
- For me the agonizing part are all the arbitrary things you have to memorize or lookup, that do not follow from the flow of the code or the principles on which the system is built. Struggling to find the right keywords to find which particular frob needs to be foozled for the program to start working, which may or may not be documented anywhere or written up by someone who already somehow stumbled across the answer.
- One of the problems - people are promoted more due to social relations so in a such environment technology becomes second class citizen. It incentivizes other qualities than being good at what you are doing.
- What a lovely message!
- It's agonizing because it's hard. It's captivating because it's possible.
- The same reason gambling is. No, I'm serious. Theres a psychological phenomenon where things which are reliably positive are less enjoyable (or addictive) than something that is disappointing sometimes and positive other times. Writing software is like that in that things don't work, then they don't work, then they still don't work, then suddenly they do.
- What you are describing is more about the frustration tolerance: In SW, you need to have a very high one, while in Gambling the addiction keeps you at the table -this is also some type of frustration tolerance, bot not the one as in a context of learning-new-stuff.
- It’s not agonizing or difficult at all, you just need like 20 years of obsession lmao
But seriously it’s easy after that. The hard part becomes:
- what do people want
- how should it look and feel
- how does it generate revenue
There’s a concept and execution phase to each of these that are difficult in their own way.
But yeah I have not stressed out about which for loop to use or if it should be monolithic or services etc in a long time. We have so many language options and you can even have a bot write it for you to the latest style and standard
