This was an interesting post, and as an older person in the industry, I feel sad for the current times, and where this person landed. Should this person have landed 20+ years ago, it would have been a much more enriching journey.
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.
> 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.
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.
>> 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.
> 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.
That sounds like toxic communication to me. I bet if you took a 10 second pause before saying something is wrong, then you would be able to come up with a form of expressing your opinion that isn't phrased in such an absolutist matter. I don't think it's fair to engage in that form of language and then put the burden on other people to "pick up on the subtext". If you're trying to make a point, make that point, don't just reduce your argument to "trust me I'm right you're wrong".
It's not a matter of trying to word it differently. You are very clearly expressing your opinion on the matter and when you say "if you are doing X you are doing it wrong" like 20 or 30 times to list a bunch of things that you personally see as "git smells", it's just easier to do it that way than explain each little situation where each smell is situationally justified.
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.
Sure but only out of context. If you take the context of the OP's lead in to the git discussion (where they state that it's only their opinion and that teams having their own ways of using git is perfectly justified), it's just a use of hyperbole to make a more pointed and concise argument.
He's right and they're wrong, though, sometimes that's just how it is. (In an actual project setting "this is wrong" incorporates by reference the thing I wrote down once so I don't have to repeat it)
But the OP literally says that it's their personal opinion and that teams all have their own ways of using git prior to going into their personal gripes with how people use or under-utilise git:
> 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.
The industry should focus on solving problems. More specifically solving the right problems, and in ways that are sustainable and maintainable.
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 hear you that it's important for a more diverse set of people to contribute to computing as an increasingly impactful field.
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.
But to be clear, they shouldn't expect high paying computer jobs to be an ivory tower for themselves so they don't have to interact with and get along with a diverse group of people (including gasp extroverts and marketers).
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."
>Those people are not broken and do not need fixing.
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.
I mostly agree with you but you did say that this is something they need to work on. Which is definitely not true – just look at the world.
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.
I think you're trying to coddle people who have interpersonal deficiencies and it's to their detriment.
>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.
I’m not coddling anyone. I’m simply saying the way the world really is.
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.
Why is it so easy for people to accept that someone who truly loves mechanical things and repairing them make for better mechanics, but somehow we shouldn't respect that the people who are viscerally invested in writing better code or developing better systems make better individual contributors in the IT world?
> Why is it so easy for people to accept that someone who truly loves mechanical things and repairing them make for better mechanics
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?
To use surgery as the example, I would say "someone who truly loves medicine and healing people" not "loved cutting people open", which is the opposite.
Also, almost every lightly-experienced software developer that I encounter, these days, seems to think that they can reproduce what it took me a year to do, in a week, with $BUZZWORD, and looping in $DEPENDENCY.
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.
> Asking questions is the best way to get an imposter off their track.
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.
> There was none of that third degree shaming "You don't even know about X?".
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 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.
1984 called, they want to hire you as a consultant.
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, …).
You seem like you're trying really hard to be the kind of developer he's criticizing. If you want oversight, if I don't have the privilege of doing what I want and screwing around, I'm just gonna leave.
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.
>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
Then why do you keep mocking the idea of a professional certification?
I am baffled by the original poster's claims. The original poster claims that they're tired of the millionth LISP interpreter and want software engineers to focus on "certified real TM problems", and concludes with people should play at home and work at work.
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.
The problems you want solved are not being solved adequately because people paying for it cut corners. I empathize with your frustration but this looks like a weird take to me.
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.
> We have people dying in hospitals because the software of the heart monitor glitched or misread a sensor.
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.
> ... 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 [...] 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...
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.
Of course it will come to naught, they just want a stable job with no changes. I can sympathize (kids, spouse, relatives, actually having a life outside work etc.) but at the same time they are holding the entire programming area back.
Then maybe we shouldn't use catch-all phrases that everyone uses with different sets of traits in mind. :)
> 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.
I'm sorry, but I am really baffled by what I'm reading.
> 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.
It takes a lot of confidence to say that Python is a low quality project. I'm not sure if many people could ever say that, but I'm sure the people that could would never.
Having plenty of criticism doesn't mean it is a bad project much less that you are capable of criticizing it from a point of view of calling it crap. If you take yourself as a better thinker than Guido van Rossum then I will need to see the proof.
My own experiences are quite enough for me (and many others btw, I know I am not the only one) and I am not paid to advocate for / against Python. Since you already made up your mind it would be double folly to engage, and I am happily wiser nowadays about wasting my time preaching to people who don't want 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.
Only when talking in general terms without any examples. I've seen enough flaws in Python to write it off as a toy language carried by nostalgia, university teaching programs, and network effects. It's not impressive by any stretch of the imagination, nowadays you can make a much better, faster, correct and easy to code program in Golang, very likely in the same stretch of time, if not quicker.
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.
>it mainly boiled down to me turning 30 this year, having an existential crisis questioning wtf I’m doing with my life
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…
I remember hearing a quote from an architect who was working well into his late 90s (unfortunately I forget his name). He was talking with another architect who had recently turned 50 and said to him, "Ah, to be 50 again, and have your whole life ahead of you!"
You're kidding right ? We're not footballers or athletes.. at 45 I feel like I only really started to approach the top of my game in the last 10 years and I've no desire to ease up or stop learning. There's an age bias that is quietly unravelling predisposed on IT as a whole being a young industry rather than because young people are better at it.
If I were hating my job at 30 with no prospect of things getting better, I think I'd at least ask myself whether maximizing my salary should really be my priority.
The more you can save and invest before you start the inevitable slide toward disability, the better. It hits many people earlier and harder than they would ever expect.
Having savings is a good idea in general. But that's not necessarily an argument for staying in a career you hate so you can make a bit more money. Maybe it's just a particular job. But people do also choose careers that end up just being a bad fit. If that's the case, you're probably better off changing horses sooner than later.
At 30 you're less than a quarter into your professional career, and that's assuming you jump straight in after uni/college. I know _lots_ of people who had a tough takeoff after further education and only got into a "career" years later.
I didn't really start my 'real' professional career until I was almost 40. Before that I was just hopping around between different jobs, trying things, and seeing if there was anything out there that I actually wanted to do for a living.
Well, I'm 61, and I feel like I really just started hitting my stride, the last five or six years (which, I'm sure, quite coincidentally, is when I left structured employment, because no one likes to work with boomers).
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.
Having lots of older peers through my life has been a huge benefit, I think. Both for being able to learn stuff earlier than they did from them, but also getting feedback like "you figured that out decades sooner than I did!" to help find and stay on track. I aim to hit 120 experience-wise while still young enough to benefit from it.
Tech could learn a lot from the people it pushes out way too soon. Even if they're a little crotchety.
Even when I was in my 20s, I thought fellow 20 somethings freaking out about being “old” and acting like they’re seasoned in the way of life and must share their wisdom with us all was good for a laugh. I felt like I didn’t know anything and now in my late 40s I feel like I still don’t know anything but am comfortable with that.
> 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.
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.
Most of it is just cultural. 1st-world capitalism, telling me I should be a 30-under-30, hustle and work-hard, retire early and live off the interest. Also I was part of a religion at 20 that taught me I should get married young, have children young, so I was panicked early about meeting those two goals, probably to my own developmental detriment.
If you know what you want and are motivated, I think you’re quite am the lucky person indeed.
Finding a good place to work at is hard. Welcome to the workforce, I guess?
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.
> the information firehose is absolutely overwhelming and draining
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).
Some will be shocked to know that some of us have never had to implement a micro service in their lives. Some even work on embedded systems. That is to say, there is increasing specialization perhaps to take into account increasing the information overload. Sometimes in reading HN it seems like there is an assumption everyone works on backend systems or webdev or both.
I don't mean this with any disrespect, but to me this sound a bit like rambling. The author goes on a bit of a journey but I still believe he's at a point where they are still figuring out this software development thing. It's fine and I think sometimes taking a step back and taking a break can greatly improve how you approach the work you do - if you have the luxury of taking a break and doing a reset.
You might also be missing a deeper problem you aren’t event aware of.
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.
Our team is being handed one hard project after another as the layoffs and offshoring continue making timezones more and more of an issue each week. I guess you may as well burn out an entire workforce and pretend there is no consequence to that when you have to keep producing profit in a high interest rare era.
> If you squash on merge, you’re doing it wrong. If you’ve never used git blame, you’re doing it wrong. If your repo’s history is useless, you’re doing it wrong. If you didn’t add a typo fix or white line change as a separate commit, you’re doing it wrong.
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
>I agree Git Blame is useful, but squash on merge is great, and having atomic commits for whiteline changes is overkill.
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.
Yeah, I'd say "if you use merge you're doing it wrong". Rebase + squash everything is the only way to go unless you're merging a giant feature branch in... and even then, try to avoid that.
I'd staunchly disagree. Merges make sense when you develop with the patchset git style. i.e.
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.
Definitely disagree. No individual commits should ever exist that aren't safe in prod. Your intermediate commits could be any old state, plus they're not useful in the future. The unit of code landing should be the single commit unless the team as a whole does parallel development in a separate branch for a while.
I'd say that git rebase -i + squashing selectively is my favorite. I generally strive to make each commit into a meaningful set of changes than I can explain one-by-one, but if they are too big, it's harder to review.
Rebase and squash makes your bisects worse for no real benefit.
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.
The massive, massive benefit is that every commit on main is guaranteed to pass CI and represent an atomic set of changes that can safely be reverted. When something Goes Wrong, you want a simple `git revert` to fix everything, not go hunting for which commits correspond to which PR.
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.
> every commit on main ... can safely be reverted.
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.
> when you have a culture of small, atomic, well-separated commits then each commit is likely to pass tests etc.
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.
> 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.
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.
I've worked at places that enforced "good" commit messages. They didn't get read any more, they just meant people committed less often and so commits were less atomic (e.g. people wouldn't bother splitting formatting changes out into a separate commit because they'd have to write another commit message) and bisect was less useful.
Good commit messages are about 1s more work than bad ones. They don't have to be long, they just have to say something concrete and useful and instill confidence in the change. If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least).
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.
> If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least).
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.
I've talked to a lot of people coming out of coding bootcamps and I've also talked to or know quite a few who left the industry. I think the main issue is that you get tossed right into the grind after the camp, doing your sprints, being basically a high stress factory worker producing code as ordered. You never get to experience the joy of creation, experimentation, and you never get hired for less conveyor belt jobs due to the lack of interesting passion projects and things to talk about.
Imagine that, software development is actual work!
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've seen quite a few bootcamps where the future employer funded the camp for people who finally got a job. Needless to say, these places were set up for maximum efficiency. Sure, a few minor changes can be made, but the core of the work isn't changing.
> The failure confirmed the stereotypes I’d seen on TV, that if you didn’t start writing code at 10, then this wasn’t for you.
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.
As someone who was programming at 10 - Programming sucked back then! Crappy documentation, Linux was harder to install, nobody was around to hold my hand on stupid subtleties like the "define / declare" difference in C / C++.
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.
When I was ~10 or so, learning C++ by typing in examples from books and realizing the book went to print well before the code it contained could compile was a common occurrence. Sometimes you could send away for a 3.5" floppy with updated code but other times you muddled through or just gave up. This was slightly better than earlier when learning BASIC and the code was from one of the magazines so you had no chance (but the programs were simpler and often more correct).
You yourself are gaining experience at that same rate if not faster today, however. My argument is not "the gap doesn't exist", it's a more humane "you don't need to close it to get a job".
> The end user doesn’t care if your code is readable, DRY, maintainable or spaghetti code. They care that the product works as intended and does so reliably.
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.
It's not though. At the very least this really depends on the industry. IME, contrary to how we may feel, there tend to be a lot of other factors that determine eg. whether you will deliver a quality product.
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.
> 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.
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?
>Since that conversation, I’ve come to the conclusion that there are three main pillars of being a good software engineer: writing code, debugging code and reviewing code.
Not OP, but fwiw I think there are 2: Having the communications skills and domain knowledge to understand what problem needs to be solved and why, and having the technical skill to do that in the most direct manner that closely matches those constraints.
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.
I’d add the ability to communicate that problem to your first pillar. Code reviews are really just a forum to discuss and communicate the solution to a specific problem
As a software engineer, you should be doing some engineering.
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.
If you're a programmer and want to quit, I wish you'd go be an EMT, paramedic, then move up to critical care. EMS is an industry full of poorly trained idiots and the profession as a whole would get a tremendous boost if good minds and smart people got up from the computer and learned how to take care of sick people.
How many years would it take to reach parity with SWE wage, or at least a middle-class wage? It seems like a high-stress field with long hours but low pay.
I have a friend who is an EMT and another who dances at a strip club. It always amazes me that the things they complain about are mostly the same management BS people complain about at office jobs.
Most EMTs make essentially minimum wage. Paramedics make less than entry level IT and SWEs. Nurses approach median wage in our industry, with a two year education requirement and a hell of a lot more work. You have to get to travel nursing (essentially consultants for nursing) or licensed provider status to make decent dev money. Your wish is worse than useless.
>Your commit message should have a short title explaining the change and the body should go into as much detail as necessary into why the change took place, I can see the what from looking at the diff.
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.
Try reading the git logs of some of the bigger open source projects (especially the Linux kernel).
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.
Empathize with parts of the post, specially on the turning 30 part. However, this smells a lot of junior level and poor managers.
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.
How did this make it to the front page? There is nothing insightful here. Someone who isn’t very a mature got bored and wrote too much with little substance. Hard skip.
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?
>I recognise this is an incredibly privileged thing to do, not working is something that many people can only dream of.
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
>I often wonder if it's made in earnest or mostly to avoid a culture war about privilege happening in the comments.
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.
If the author's reading, thanks for writing this. I'm also about to turn 30 and dreaming about quitting my job so I can rediscover the joy of programming. Very interested in hearing about any plans you've made.
His paragraph on git was a bit muddled because every goal he had for doing git as he says is achievable without following his rules. Arguably, squashing on merging and one commit per PR enhance readability and the comprehensibility of the history. The counterargument might be that a single commit can be too large and contain too many logical changes to digest, but in that case the merge commit of 100 commits of a feature branch will still be huge (or you’ll have 100 commits from the branch on main if you rebase). Either way, bisect still works as expected.
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.
Author highlighted some eerily similar parallels to my own development, save that mine was punctuated with more hardship and fuck-ups.
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.
Article was long so I only skimmed most of it and I'm thinking 30 is young for a midlife crisis. I quit involuntarily during the dot com bust and became self unemployed running my own "business" for a few years. It coincided with my peak midlife crisis years - late 40s. I eventually got back into programming which came as a huge relief, and the main goal became getting back on track for retirement. I managed to avoid divorce and managed to retire.
> Your history should be clean and easily readable.
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.
Work sucks, but these are some exceptional assholes. Not everything is this bad. There are teams out there with well adjusted people on them.
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 just resigned from my job as a software engineer (~9 years of experience) without having another job signed. Best decision I have ever made. The second I did was the second the curiosity and eagerness to learn things came back.
>Writing code is creative, its like art. Debugging is like science
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?
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.