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).
:-))
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).
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.
This is the real reason hackers start start ups.
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.
1. unrealistic time frames and expectations from non-technical managers, and
2. leetcode
Everything else is awesome.
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.
"In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment."
"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...
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.
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
-- The Mythical Man-Month, Frederick P. Brooks Jr.
Can't have the rainbow without the rain as they say
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.
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.
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 guess programming to me was always an excuse to do math, not necessarily to build products.
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.
Never some intractable bug, that didn't seem to have any relation to the source code you're reading?
I've never punched the air after fixing some bug that I didn't at some point earlier get extremely frustrated at its intractability.
But seriously, sometimes its not the code, it's the human factor that's painful, other times, well it's 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.
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]
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.
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.