Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • This is one of my favorite quotes from Brooks:

        "In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment."
    
    Was this AI paraphrased? From the article:

        "In practice, real authority comes not from titles but from influence built through consistently delivering results."
    
    Same meaning, different wording.

    Full book: https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythic...

  • 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.
  • 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.
  • 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.

  • 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?

  • Yeah same. I've been doing this for fun since I was like 9 years old. 30 years later it's still fun.
  • 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.

  • Because you get to solve real problems people have. But you have to work with real people.
  • 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
  • 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.
  • > 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.

  • 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.
  • 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.
  • 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.
  • 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.

  • 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...
  • > 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).

  • Becauuuuseeeeee ...at home you can be "The Duct Tape Programmer" - https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...

    :-))

  • 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).