Reflections on quitting my job
mooseyanon.medium.com
mooseyanon.medium.com
When I started, the industry was opaque to most, you got in as an intern with the knowledge that you knew nothing. Information was shared freely, things were shown to you. There was none of that third degree shaming "You don't even know about X?".
People understood the technology under their own work. They understood that things were complicated and hard. They didn't act like they could do it all, overnight.
I hope that this industry turns it around, and refocus on the prime objective: being nerds. Being excited about milliseconds improvements, excited about the small things, discovering and learning through curiosity... and not being insecure cockwits, that have to jam their superiority in other's face at every occasion because they, deeply, know how replaceable they really are.
The paragraphs about git were interesting, in the sense that the author, also suffers from the industry's "I'm right and you're wrong" motto; and that is the reason, by the looks, that they've left. There is some unresolved conflict there! "I'm tired of people acting like rockstars", and proceeds on a rant doing the same thing.
I suggest you never use those terms of affirmation and ask questions instead. Asking questions is the best way to get an imposter off their track. And if this person actually knows what they're talking about, the answer will enrich you.
That’s not the industry’s prime objective, it just happens to be who it was accessible to early on.
If anything, the industry should focus on being more well rounded and less focused on being nerds.
The way I read keyle's point is that computing is also a home for many sentient humans who feel awkward in meat space but whose creativity blossoms in regimented systems of abstract logic and in electronic workshops capable of infinitesimally cheap symbolic manipulation and storage. Computing is good for society, and it's also a therapy / practice / haven for a percentage of fringe humans.
People like that really need to work on fixing it. It can obviously be crippling to their career and lives.
Which is the point that the comment I originally replied to was making. "Let's keep tech for just the nerds, as it should be."
Stop trying to put words in my mouth to bolster your point, or virtue signal, or whatever your motivations are. I never said they were broken. It's an important skill that needs to be worked on and improved, just like any other life skill.
Why would there be awkward weirdos if they needed to work on not being awkward weirdos?.
The can choose to work on it, but they can also choose not to, by say trying to isolate themselves in an industry where they think they can minimize human interaction.
There might be consequences of their choice though. Their personal life might suffer or they might get fired from their cushy job if people don't like working with them. Those things might push them to make a choice to work on their issues or they might not.
I think society should create incentives that reward well-rounded people (and to an extent it already does). And I think it's important to realize that people need to do almost nothing.
>There might be consequences of their choice though. Their personal life might suffer or they might get fired from their cushy job if people don't like working with them.
This is why they need to work on it. Unemployed and ostracized from the industry with no network to fall back on doesn't usually end well.
>Why would there be awkward weirdos if they needed to work on not being awkward weirdos?
People can be an awkward weirdos all they want, but they need to know how to turn on some facade they and other people are comfortable with when necessary.
People have agency and they can choose to fuck themselves over as hard as they want. Either actively by drinking themselves to death or cheating on their spouse (for example) or passively by choosing to be an anti-social weirdo nobody likes who works with computers.
Nobody needs to not cheat on their spouse. But they can choose to not do it.
> Unemployed and ostracized from the industry with no network to fall back on doesn't usually end well.
This is true, but it’s their life not yours. You can tell someone what they need to do all you want. Good luck with that btw.
Get over the idea that anyone needs to do anything.
Instead realize that people can choose to do whatever they’re motivated to do. And a lot of people are motivated to be miserable. And they’re not going to do anything about it. They certainly don’t need to.
They need to work on it or their life will most likely suck. That better? I feel that was implied in my original statement:
>People like that really need to work on fixing it. It can obviously be crippling to their career and lives.
There an unhealthy obsession with technology for the sake of technology...but no one care. Not a single user is going to say, "I love React" or "Why didn't they use Vue?"
A great technical solution to the wrong problem is no solution at all. Clients and users want their problems solved.
I don’t accept that.
I knew a surgeon.
He truly loved cutting people open.
If you went to see him you were getting cut open. He’d find a reason.
Is he a better surgeon than the one across the hall who’d refer you to somebody else if there was a decent chance non-surgical intervention would help?
Don’t show me the person who loves code quality. Show me the person who likes helping people use technology.
This is what companies have come to expect with DevSecOps.
This should be at the top of the page
This is not my imagination, as it is usually the basis for them sneering at me, and thinking that I'm somehow going to walk away both chagrined, and impressed by them.
I don't necessarily think that's "I'm right, you're wrong". Instead it looks more like just being strongly opinionated on the matter.
As someone who is very opinionated on git and VCS in general, I get it. The difference in experiences between projects with good, clean, descriptive git histories (see most projects that follow the linux kernel/git patchset approach), projects with linear PR squash histories, and projects with lots of useless "fixup", "fix", "try again" type commits is utterly and entirely massive.
It's the type of gripe that I personally would place alongside projects not having good unit testing. A project can still be workable without them but I'm going to fight like hell to get things fixed up so we can move fast in the long run.
> I don't necessarily think that's "I'm right, you're wrong". Instead it looks more like just being strongly opinionated on the matter.
Are you honestly making the claim that the part of the post that repeatedly states "You're doing it wrong" isn't saying "I'm right you're wrong", but rather just being "strongly opinionated on the matter?"
It reads very tongue in cheek to me because I have gone on those types of rants in the past. And I've known a number of other people who hold similar stances and they also do the same thing.
Like I've literally gone on a "if you do X you are doing it wrong" rant about git verbatim when trying to explain patchset etiquette in the past. It's not trying to say "you are always wrong for doing it this way", it's just way too long winded and difficult to explain your point about should be versus shouldn't be done in your view while being nuanced and pointing out that they are sometimes okay. You just say "if you are doing X you are wrong" and hope the reader picks up on the subtext that you are just making a point and not trying to be authoritative. It's a lot easier to do in person but alas.
> Every software team in the world has its own culture and ways of doing things, which is all good but when I see teams using git as a glorified `ctrl + s` it really breaks my heart.
>
> This should be its own blog post (one I’m planning on writing) but these are some of my general issues with how I see teams use git. I apologise in advance for any hurt feelings but here goes…
It's not "I'm right, you're wrong", it's hyperbole. They are using an exaggeration to drive home a point and at the same time making that point in a more concise manner.
Maybe instead of saying "you are doing it wrong" you could say "you are underutilising git" but even then that only applies to some of the things he listed and not others. Hence it's easier to express that what you are saying is your opinion and then use hyperbole (i.e. "you are doing it wrong") to make a concise point.
The OP does this prior to going into their list of gripes:
> This should be its own blog post (one I’m planning on writing) but these are some of my general issues with how I see teams use git. I apologise in advance for any hurt feelings but here goes…
It's only them definitively claiming that "I'm right and you are wrong" when taken out of context from the surrounding article text. But within the context of that article, it's just a use of hyperbole to make a concise point.
I hope not. We need more structured approaches, I personally vote with all hands the amount of "play" we do to be drastically reduced, enforced by revoking a professional license even (if our industry ever gets regulated).
I am sick or nerds reinventing wheels because they are privileged and bored. Like I ranted recently here in HN, can we stop with the millionth LISP interpreter already? We have people dying in hospitals because the software of the heart monitor glitched or misread a sensor. Can we get on those problems instead? Like, before the 41th century for example? When will we get to do something genuinely useful that actually, [gasps], helps people?
[takes a deep breath]
First order of business: rework our interaction with the OS the command line, stop all the legacy lunacy of TTY and many others, and figure out one way of doing things. Do it on Linux. If Windows and macOS don't want to play along then too bad, the devs working there will have a miserable time, and that will introduce pressure from them to Microsoft and Apple to play ball.
Let's go. No more nerds. Let's be correctness + simplicity fanatics, I say.
> I hope that this industry turns it around
It will never do that. Let's not forget we are workers paid to produce value. Let's also not forget that IT is always viewed as an undesired cost center -- I hate it as much as every programmer but it's how people view us and curiously enough, that perception is very persistent.
Many people understood we need to "play" to gain more knowledge but these times are mostly over, at least in popular development categories like web and mobile. Most people there -- myself included -- are paid to assemble IKEA furniture, at least 90% of the time. Creative tasks are few and far between, sadly.
> The paragraphs about git were interesting, in the sense that the author themselves suffer from the industry's "I'm right and you're wrong" motto that is the reason, by the looks, that they've left. There is some unresolved conflict there.
As a guy who started 20+ years ago -- like you alluded to these times being more lax (which I haven't observed but then again I never lived in the USA) -- I stand with OP here; appealing to popularity and cult of personalities are sins I didn't imagine the programming area will suffer from, yet it happens every day. Try criticizing one of Python's many obvious pitfalls (no, I will not elaborate, they have been described a million times, including here on HN) and you'll be buried under a mountain of "millions are using it successfully every day, have you considered that you are the problem?". As if the amount of supporters of a thing ever had any correlation at all with quality but hey, don't tell them that (tidbit: burning the "witches" in the middle ages; I bet 99% of the time somebody had a beef with the neighbor lady and they set her up as a "witch" to get rid of her).
--
I share your nostalgia about how things were done long ago but I really hope we emerge more disciplined, structured, and much less bikeshedd-y out of the whole thing.
Play on your own time, not during work.
Also being a nerd doesn't mean playing at work. I'm not sure why you push my view as a lack of discipline or being lax.
> I never said anything about reinventing the wheel.
You did not indeed, yet this is what I have observed 100% of all nerds I ever knew in my life doing over and over again. Sorry, I am a bit jaded but also quite justified in my opinion if you take my life + career in mind.
> I'm not sure why you push my view as a lack of discipline or being lax.
Interpreting your words, nothing more. If you feel I did it wrongly feel free to elaborate. I'd be interested to read it.
You're on! Okay, I will need
- the make and model number of this unit, and whatever documentation is available describing the glitch: what to look for under what conditions; steps to reproduce and such;
- the hardware itself: some contact person who will send it to me;
- SDK for the thing, and firmware codebase, with some documentation: how to build, flash;
- contact information for where to send fixes and have a related conversation;
- all of the above free: I will fix the problem, but I'm not paying for anything.
Until I have these things, I'm working on my pet project with what I have available.
>- the make and model number of this unit, and whatever documentation is available describing the glitch: what to look for under what conditions; steps to reproduce and such;
With just that and the allegation of a particular glitch harming a person, you can report it to the manufacturer and they're legally compelled to treat it as Serious Business (I don't think that's actually the FDA's term for it), though that doesn't strictly speaking guarantee a timely fix.
...Though not sure how well are the SDKs documented...
A lot of simple and correct things were built by passionate people, and play is a necessary prerequisite to nurture passion.
As to the amount of play to be encouraged in a work setting, I don't have a strong opinion yet.
Python gets plenty of criticism, you might have just made sure you're never going to hear it.
If you are comfortable with Python I can somewhat envy you -- you likely have a cushy job and not much changes. Enjoy it while it lasts because take my word for it, it's a turbulent world outside of your bubble.
But in my eyes people with your mindset are enabled through their privileged position and thus become complacent.
It's OK to disagree. I also thought I'll share how I view you (in addition) and will bow out.
And its main selling point nowadays, ML/DL? I hear Rust's Polars is catching up. Python should enjoy its place while it lasts because I am seeing a good amount of effort for it to be displaced, from many directions.
I am not making anyone believe me though. Most programmers feel easily threatened when their favorite language is criticized and I've come to accept that defect in human thinking. But I won't be pretending to believe in a mass illusion. I moved on, long ago, and I've seen increases in productivity and correctness and [machine + development] speed.
Regulated industries should produce high quality output, agree. But the moment that approach leaks into the rest of software I’m out for good, and I imagine many others along with me. The “real” and certified™ big boys can take over all the work for all I care, but there’d be substantially less output across the industry. (Some backwards people would call that a win)
Note that I specifically left a much more regulated industry to be in software. Also note that I care about correctness and quality a lot still, it’s one of my favourite CS subtopics (memory safety, business logic in the type system, (fuzz, property, unit, integration, e2e) testing, …).
Damn. I want such a programming job.
It kinda reminds me of the "passport bros". You want to MAKE me do housekeeping, and there's NO way to get someone else to do it? I'm just gonna leave, and have fun suckers.
You're really smug about "certified™ big boys", but you're just the counterpoint to them. The "certified™ real deal developers", chime in to talk about how they'd never accept oversight, but yet there's very little substance here.
I hope you have some reason. You feel that this is a waste of time and too much effort gets spent on CYA and BS, that the "real process", and things that really keep the system safe and secure get ignored (like having super smart certified™ real deal developers), and the checks and balances (like in the process) do nothing to help... maybe this isn't your pitch, but I imagine there's something; yet you haven't shared these ideas.
In any case, I think you're wrong. We don't have enough regulations, especially in safety and security critical applications. We need discipline and standardized methods in software, as well as regulations in important areas.
Even if you were making real points, we'd have to doubt your motives, but at least you're not sneaky enough to hide them.
Then why do you keep mocking the idea of a professional certification?
1. Except, the millionth LISP interpreter is almost definitely a hobby project, so their claim that people are screwing around at work is bogus.
2. What drives people to work on problems (in industry) isn't "what the nerds find cool", it's money. That's a capitalism problem, not a "this industry isn't controlled enough by me" problem. The most lucrative jobs are in enterprise SaaS and ads companies, do you think engineers flock there because that sounds fun?
3. The software industry isn't uniform. Medical devices ARE regulated under the medical industry, commercial airplanes ARE regulated under the aviation industry.
Has there been recent disasters in those industries due to software? Yes, and regulation gets updated. Regulation gets written with blood.
You might argue that software feels like they're the most prominent, but I argue it's because:
1. Software is relatively new
2. We are software engineers, so we take notice of software more.
Mechanical and civil engineers are not immune to human-injuring mistakes. Think of the last car recall due to mechanical failure (heck, there's one this year due to brake manufacturing issues: https://www.caranddriver.com/news/a44475030/honda-acura-brak...). Or the O-ring failure in the space shuttle Challenger that caused it to explode mid-launch.
> The most lucrative jobs are in enterprise SaaS and ads companies, do you think engineers flock there because that sounds fun?
It's not even specific to these industries! HN has a very myopic view of the world. This is true for a number of engineering disciplines.
How many people are REALLY passionate about making trash (basically a job I held as an EE)? They pick up these manufacturing jobs, because they're reliable money makers. What was I doing? Taking a machine and creating a copy right next to it (with modifications).
Now I'm working in software and largely doing similar things. Integrations, design, architecture... basically accounting work with templates for code. I do a fair amount of embedded system design, but the software design pretty much decided.
> 3. The software industry isn't uniform. Medical devices ARE regulated under the medical industry, commercial airplanes ARE regulated under the aviation industry.
There are software safety standards, but they can be treated as suggestions.
What happens to me if I simply decide not to follow regulations? There's very little. It's comparable to legal, accounting, and other engineering work that has real consequences attached to it for doing it wrong. Loss of profession or jail time.
In Europe, more stuff requires a stamp. I work in an industry where we have these conversations. The "real developers" and the "big boy serious developers". I'm just shocked he can have such short-sighted interpretation.
The serious big boy developers have their problems too. People just have to choose either extreme side of a spectrum.
Hear hear. The last 10 years of my career I was surrounded by this attitude (about Python); there was literally no possibility of putting a dent in the groupthink and cult-think surrounding Python (because after all, wasn't it "the most popular programming language in the galaxy"?), which eventually became the corporate-ly mandated language for all software development (and that was that). Yet when I retired in late 2021, my employer's minions were still developing almost entirely in Python 2, having half-heartedly put forth multiple parallel Python 3 migration initiatives which had largely come to naught.
/rant
> Like I ranted recently here in HN, can we stop with the millionth LISP interpreter already?
Except, the millionth LISP interpreter is a hobby project, that people are making on their own time, not during work? I get it's annoying to see something you've seen before, but you know, you can ignore it.
Play is an important part in learning. The millionth LISP interpreter, game engine, whatever is fine. From my experience, the people building these things gain a lot more valuable experience than just doing college or even just having a prior job.
> We have people dying in hospitals because the software of the heart monitor glitched or misread a sensor. Can we get on those problems instead?
Do you have any idea how current problems actually get decided for in industry (not only software, but in general)? It's not "this problem gets tackled because it's cool", it's because of money. Do you think bright software engineers love working on Microsoft Word or better AdSense because they think it's fun?
Also, this sounds really stupid to say, but this seems to be what you're implying when you say "keep play out of work": do you really think the same people working on embedded systems for heart monitors are the ones writing LISP interpreters...somehow...at work?
There's also something that plagues HN and it's that they think the software industry is somehow uniform. Medical devices get regulated under the medical devices industry, commercial airplanes get regulated under the aviation industry. The pure software industry is not the only place that hires software engineers.
> Except, the millionth LISP interpreter is a hobby project, that people are making on their own time, not during work?
You are likely correct though I still have my doubts, I've encountered pretty privileged individuals around here, commanding $250k - $400k a year with practically zero supervision. So I do wonder still.
> Play is an important part in learning. The millionth LISP interpreter, game engine, whatever is fine. From my experience, the people building these things gain a lot more valuable experience than just doing college or even just having a prior job.
True, I am simply jaded that everyone is always "learning" and I don't see much progress in almost any area in programming. We still tip-toe around outdated concepts and implementation that people are too afraid to touch and start revising. It has gotten infuriating as I get older and older.
> It's not "this problem gets tackled because it's cool", it's because of money.
Oh I know, believe me, and here I am not faulting the programmers, I am faulting the completely broken system that is so detached from the problems that this race needs solved that they might as well live in an adjacent solar system...
> Do you think bright software engineers love working on Microsoft Word or better AdSense because they think it's fun?
You haven't seen the long diatribes of people working there who build a mental labyrinth and go out of the other side triumphantly claiming that they are doing good for the world. I wish I could forget seeing these comments, that day my faith in humanity has plummeted, like a lot.
So yes some of them not only see it as fun but also as a good thing to do.
History will judge them but sadly they won't be alive at that time.
> Also, this sounds really stupid to say, but this seems to be what you're implying when you say "keep play out of work": do you really think the same people working on embedded systems for heart monitors are the ones writing LISP interpreters...somehow...at work?
See above. I am sure some do.
> There's also something that plagues HN and it's that they think the software industry is somehow uniform.
I hear you, it's a common defect in human thinking when we get frustrated and I am not an exception, sadly. I am mostly commenting on the usual state of affairs and the most visible parts. Otherwise you are right and I agree with you.
--
All in all, my comment upthread was borne out of long-bottled frustration. I can't see almost any progress in almost any software venue, people are too happy to keep tinkering in their own miniature corner and then emerge on some forum and claim superiority (reference: KDE vs. GNOME forum threads, one of the ugliest human discourse I've ever seen), and in the meantime the entire computing industry is sitting on ancient implementations that only get drivers added (like the Linux kernel; an amazing project that I feel is a shining light of the free software movement... but to this day security is not their priority).
I can go on and on. But the TL;DR is: I really hoped we as a collective area will have more balls. Seems like we're just tame nerds that only do what they're told.
Shame. That's breaking my heart. Hence the frustration.
This is nonsense based on nostalgia, no better than “I long for the days when men were men” or “kids these days don’t respect their elders like we used to”.
To the point specifically about being a newcomer to the software industry, there are definitely challenges that I don’t want to underplay. But there are also more resources, more types of resources available than ever before. Mentoring junior ICs is something that is explicitly rewarded in many tech companies, making it easier for them to find mentors.
If you have some actual data that compares the ease of joining the industry compared to 10 and 20 years ago, please share. But if you’re just waxing lyrical about the good old days, please don’t.
I think this is more of a function of people who hire than people who work. Its an an interesting industry that obsesses itself with imposters, which is pretty much the experience of working for, or trying to be hired into any tech company.
Actually, the prime objective of the industry is to create surplus value for the capitalist ruling class.
The second software engineer becomes replaceable by AI they’re all gone.
I cannot count the number of times I had various age-related crises. I’m in my 40s now and I’m starting to be a bit better about it. It’s not until you get a few decades into adulthood that you realize how young 20, 25, 30, 35 are. And I’m sure there are some folks in their 50s or 60s who will tell me that I don’t appreciate how young 40 is…
At 30 you’re well into your professional career.
Where is the fun part though ?
I'm pretty happy with the work I do now. I feel that it knocks the stuff I got paid to do, into a cocked hat.
The coroner is going to have to rub "YTЯƎWϘ" off my cheek.
Tech could learn a lot from the people it pushes out way too soon. Even if they're a little crotchety.
How much of it do you think that is related to your environment and socioeconomic condition?
I ask that because I'm more or less of your generation and I know exactly what I want and I am disciplined/motivated around that, but due to my demographics/socioeconomic condition, the only crisis that I have is that I do not have the right passport/continent and/or financial resources to pursuit it.
If you know what you want and are motivated, I think you’re quite am the lucky person indeed.
I only had one job in my life that I truly loved. Years later and the team is still on a Slack instance, chatting it up once in a while.
That said, the tech sector in general has changed. The elders remember when this job might have been unstructured and demanding but still fun. We got stuff done, and we felt productive.
Now, the young engineers are settled with unnecessary complexity and the microservices grind. It's not you - it's stupid. It's just that the younger devs think this is how it is, but this is fairly new. In addition, the information firehose is absolutely overwhelming and draining. So there are some pretty big things happening at the same time.
The good news is that the industry is reconfiguring to the "lean times" (read "regular, non-diamond-hands and non-ape-NFT economy), and it's going to get a little better.
holy shit yes. And also contains only trace elements of usefulness. The problem is having to sift through the mud to find the hidden shinies. That's the draining part.
I've taken to ignoring most of it until it reaches "stage 2 importance" at which someone will direct message me or come and talk face-to-face about it. Only then has it reached a worthy level of priority.
Trigger warning: I have 2,957 unread emails in my 14-month-old mailbox (they stay unread until I've actioned them appropriately).
Startups and companies have had huge layoffs and haven’t been hiring and instead making their existing staff take on all the work.
You may have quit because you were getting run down and burned out from having to take on too much for too long.
It happened to me.
I quit my job same time, at the time it was because I was frustrated by so many pressures from my family and work at the same time and I got to the point where I just no longer gave a shit.
I was the #1 star performer having all the ideas and carrying all the heavy lifting and after several rounds of me asking for a promotion and being turned down, I just quit right before a big project shipped after getting fed up with being micromanaged.
So you may have just been on the wrong of the economy without realizing it.
I came to realize I was so burned out, I have had a couple months off and I still am not ready or excited to go back.
I agree Git Blame is useful, but squash on merge is great, and having atomic commits for whiteline changes is overkill.
Looking forward to that fleshed out blog post on git
1. Write a bunch of code and just scratch it out, stashing in your `FEATURE` branch until the feature is done.
2. Rebase that `FEATURE` branch into sane commits that each accomplish an atomic substep in the implementation of your feature. Each discrete commit/change should build and pass tests.
3. Open your code for review, either via a PR or by submitting the patchset to a mailing list.
4. Implement requested changes as a `FEATURE-v2` (or `FEATURE-vX`) branch.
5. Rebase your `FEATURE-v2`/`FEATURE-vX` branch to clean up your changes and get them to roughly line up with your "final" commits from your previous `FEATURE` branch.
6. Submit your new patchset revision to the mailing list in reply to your last patchset revision. Or if you are using pull requests, change the merging branch from `FEATURE` to `FEATURE-v2`.
Then cycle back to step 4-6, rinse repeat until everyone is happy. Then you merge in the final `FEATURE-vX` branch.
This leaves you with a history where each individual commit is a useful, descriptive, and fully functional change to the codebase but also with a merge for the full feature at the top. That's important because git tooling actually can iterate over all commits or over only top level commits without traversing into merges.
Then it's way easier to identify which feature introduced the issue in question and you can easily peek into the feature's individual commits to understand each discrete change and exactly what the intent was.
OP is wrong about commit messages ("fixp" is fine, most of the time you're not going to read the commit message) but right about everything else on the git side.
But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
Sure. But the point is to get away from doing those "complicated arduous change"s, and split them up into much smaller pieces. Being able to commit without breaking your flow helps a lot with that.
> But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
This is a purely circular argument. "It's important to have high quality commit messages so that you will have high quality commit messages". It really isn't.
It also means that when you git bisect, you know exactly which PR introduced the issue. The exact commit that did so isn't as important, because there's no way to ensure that it's safely revertible.
Hardly. You know that master-before-that-commit passed CI, sure, but you don't know that reverting it isn't going to interact badly with subsequent changes or subsequent stored data.
> It also means that when you git bisect, you know exactly which PR introduced the issue.
Finding the PR from the commit is a one-liner. Github will even show you right there on the commit's page.
> The exact commit that did so isn't as important, because there's no way to ensure that it's safely revertible.
In my experience reverting a single small commit is a lot safer than reverting a full PR that may have e.g. added a value to an enum that's stored in the database, and when you have a culture of small, atomic, well-separated commits then each commit is likely to pass tests etc.. Also if the commit is a few lines then you're much more likely to understand why the breakage happened, rather than blindly reverting a big PR because your test passes before but not after, which is good for safety. Of course you need to test the revert but you always need to test the revert.
This is why it falls apart: culture is really hard to scale. If you don't have mechanisms in place to enforce this behavior, then people are going to drift. This is extra true for commit behavior, because it doesn't matter how a PR is broken down into commits; CI doesn't run on every commit. So when things Go Wrong, it is very unlikely that the buggy commit had CI run on it and the commit before, so it's probably not atomic.
But the PR always is! PR's pass CI, and the main branch does too. Sure, not every PR is safe to trivially revert, but reverting a PR will always put the codebase in a known previously good state that passed CI.
You can run CI on every commit if you want, or have a pre-commit hook to run tests, or just accept that it won't be 100%. In my experience running the build+test when you commit is self-enforcing, because otherwise you end up hitting a failure at the CI stage and that slows you down.
> So when things Go Wrong, it is very unlikely that the buggy commit had CI run on it and the commit before, so it's probably not atomic.
If you allow frequent commits then commits are more likely to end up atomic. But also the worst case is that you fall back to what you had before - your bisect script should already skip commits that fail in-tree tests, so in the worst case your automated bisect reports that the break happens somewhere in the range of commits that's one whole PR. Usually you do better than that.
FWIW this is something you see commonly on mailinglists. Each line you modify in a given commit is assumed to be specifically related to the change described in the commit description. It's just easier for reviewers when you break whitespace changes or non-semantic text changes out into separate commits so that they don't have to try and figure out which lines are semantic changes and which aren't.
Given that people who work with patchsets tend to do a lot of rebasing in their workflows, they are generally familiar enough with rebasing to just split out a set of changes from a given commit into two commits in a minute or less.
Having said that, yes, it's tiresome, but it doesn't have to be that way. People with influence at your workplace can change things to be different/better/more fun. You can change things for yourself. If the workplace is nothing but a grind, people at that workplace have made a choice, implicitly or explicitly, to make it so. It's not that way everywhere, in my experience not even at majority of software development jobs.
I always find railing hard for or against this particular stereotype to be tiring. Both of these things can be true:
* The kind of person who starts writing code at 10 might have a huge head starts in terms of acquiring the crystallized intelligence that makes them succeed in this endeavor. Heck, it may even indicate some passion for it that will help them succeed through their entire career anyway.
* The market for programming is so strong, and programming itself so fun of a hobby once you reach some critical mass of skill, that it's still worth getting into even if you didn't get into it at 10! A head start is an advantage, but it's not a decisive one in this endeavor.
Those competitive lifters they train in mainland China are a much starker example of the kind of thing where it genuinely might not be possible to overcome that head start. If you make it. Which a great many teenagers don't. Even so, nobody in their right mind would claim that to go from no exercise to lifting 2x a week is a bad idea.
Focus on what you can do at the margin! The margin is always human scoped by definition!
EDIT: Later the OP talks about this very thing in sports. I hereby eat my words. Mean culpa, OP! It's always nice when 2 smart people independently arrive at similar points.
I figure everyone who starts today is probably gaining experience at at least 2-3x the rate I was learning back then. Plus I was a kid, I learn faster now that I know how to learn.
Well, they don't today. But you or someone who has to maintain it will tomorrow, and then the customers will follow when the quality of the product degrades because the code is unmaintainable and there is extremely high risk of breaking something accidentally when you go in to touch something seemingly unrelated.
I think developers have a difficult time communicating the business values of code quality, and what code quality means. I think senior developers often have a hard time communicating these things to junior devs as well, which creates a sense that the old timers are just dogmatic ideologues who don't have good reasons for asking for certain changes. I realized this when I once had a manager point out to me that I was coming across as some type of esoteric "purist" when I spoke of "clean code."
The value of software is its ability to change. Change is baked into software by definition. Otherwise we could just stick with fixed circuits and be done with it. They are cheaper to build and have practically zero maintenance costs (other than perhaps replacing hardware components that wear out). So every line of code is served by understanding when it is written that there is a high likelihood that it might need to change at some point.
There are a lot of causes of burnout in our industry, but one I hear often is that code maintenance is an nightmare, that debt tech is overwhelming and that leadership gets annoyed and just looks for "more developers" when new features they are asking for can't be delivered as quickly as they could when the project was greenfield, and that customers are complaining because the system doesn't scale and is running far slower than it did when they first bought in.
I guess what I'm trying to say is that readable, DRY maintainable, non-spaghetti code IS pragmatic.
This is something that I struggle with a lot with the mainstream engineering literature currently available that has a lot of empiricism packaged with opinions, especially folks who worked only in some specific setups in terms of demographics (e.g. SF and USA generally) and resources (e.g. FAANG companies, Mid-Caps, companies with infinite amount of money pre-2021).
Where do you folks get scientific or empirically reliable information about practices and methods in Tech Engineering?
Software quality ends up being a lot like design quality in other engineering fields, but guess what? The same dynamics emerge. You have ivory tower management types and fire fighters.
The fire fighters keep the machines running, and get new programs done. As a consequence they often drill through shit and fuck things up, without documenting.
In a huge number of scenarios this ends up being how the sausage gets made. In the end, reality is FUBAR'd compared with the expectations.
You really miss it when you don't have it, but you're also ignoring a extremely high percentage of the time nobody cares, and people are busy with more important things.
Not even close, my guy.
I'd argue the more important big 3 are obsession, organization, and ambition
Sometimes you need to get better technically, sometimes you need to get better at figuring out the problem (solving the wrong problem isn't worth a lot. regardless how "clean" it is). Sometimes you need to get better at figuring out what you need to get better at.
What that means is taking fuzzy human problems, expressing them as rigorously as needed, and solving them as cost-effectively as possible.
Code is the means by which you express and solve a problem, not the whole process. Saying software engineering is about writing code is like saying civil engineering is about arranging girders in CAD: it's funny, has a grain of truth to it, is probably what your mum and dad think you do, but is a very surface-level understanding of what's going on.
Where's the requirements-gathering? Where's the scoping? Where's the evaluation of different implementations? Where's the risk analysis? Where's the human planning for change management? Where's the part where you go and read a textbook on dimensionality reduction to try to understand the recommender system? The empirical understanding of the running system? Where are all the other things that go into building and running a software system that are the engineer's responsibility and aren't just code?
EDIT: Not to say that getting good with your tools isn't a massive part of the job! It's just...the part of the job where you plan everything out is as important as the part where you pick up your tools and begin. When you start working as a software engineer, everything is about code because you need to know how to code as a foundation. All the other stuff comes later.
Prime ministry of my country in EU has the same salary as regular "senior" engineer from local bodyshop like Epam.
That sounds tedious like commenting every line of code. You might have to do this if the code is hard to read and maintain though. Most of the time the why is "because feature X demands that it change".
Maybe it's just me, but I prefer squashed merges because lots of small commits are also annoying to switch between and if I'm diving into git history, I'm investigating and have some extra time to understand everything instead of relying on commit messages.
Those really show why those commit messages are useful to figure out why things were done the way they were ("what the dev was thinking"). This is especially useful if some kind of bug is found 2 years later and someone who wasn't involved in the original change needs to fix it.
The git rant, the 3 pillars of being a good swe, the working code trumps good code ... All thoughts feel in the right track and motivated by experience, just maybe not enough experience to see things aren't <that> simple.
Are we really supposed to be committing after each logical block of code or change? Like a white line fixup or a small new function added?
And what the heck is he going to do for money? I didn't seem him mention a new job and he's sleeping until noon on a Tuesday. How do people live knowing their savings is slowly disappearing and nothing is on the horizon?
It's crazy how often you see this kind of statement these days. I often wonder if it's made in earnest or mostly to avoid a culture war about privilege happening in the comments. Would love to see the Google Trends data on this
Interesting point. Cynical me would guess the latter. The culture warriors want you to apologize for your hard work, which they most likely aren't vaguely familiar with.
Putting all the info in the git commit message is a hopeless cause, I think. Even if the message is relatively fulsome, there’s still the context of the change to be found in the JIRA ticket or the Confluence page, and you either leave that out to avoid dead links, in which case context is lost, or you include links that eventually get stale and die. I don’t know of a good solution to this except the fact that large enterprises often have dinosaur systems that are like ancient Mesopotamian pyramids, full of secrets from the past. Honeywell suffered some breaches a couple years ago that necessitated rebuilding a large number of systems, and when they got around to the ClearCase systems still in use by some teams, no one had the intestinal fortitude, let alone the knowledge, to rebuild them.
That said, I can’t remember ever seriously digging into the history of a repo to find who implemented something or how it changed to become what it is currently. I’ve worked on very large repos and implemented significant, wide-ranging functionality, and historical exploration never helped me understand the current code or the overall design—if I didn’t have architecture docs I read the code and made my own (in which case I’d rather the effort of a commit message was put into docstrings instead), which did far more to help me grasp a codebase than scrolling through git log.
So if I would add one thing to his essay, it would be this: find some undocumented code as document it as you would like it to be. Reading code is an underappreciated skill in our field.
This reads like a plain need for a sabbatical, or vacation. Maybe even burnout. Fun or "being in love" with work is fickle and generally unsustainable in industry, or depends on factors that are sure to shift (e.g. novelty, colleagues, level of responsibility, etc).
It would be one thing if an opportunity for something better presented itself, but at face value it seems this wasn't replaced with anything. Unless you plan to lean-fire your way to the grave, another SWE gig is probably in your future, and it will not matter whether you fall back in love or not.
Yes so much. I've harped on it a great deal here, but clean history is a big deal, and that does mean learning to love rebasing.
> Each commit should contain one logical change and ideally pass CI.
Well, at least ones that are expected not to pass CI should be labeled so, because it's useful to first push a change to tests that shows there's a bug, then push the fix to that bug.
People like those examples exist in every industry though, they'll just present them selves differently. I had a manager ask me if i was a retard on the sales floor when i used to stock shelves.
I feel like writing code might be a science too. Coding science? Programming science? How about Computer Science? Or maybe coding software systems is more practical. Maybe it’s engineering?
No, you’re right. It’s Art. Save the science for after you’ve written it and it doesn’t work, amiright?