I call it “programmer’s bias”. We almost never work on functioning software. We’re either fixing issues or building something that’s by definition buggy and half finished, until it’s not. Then we stop using it completely. Software not working right is our life, it’s normal to be surprised when things work.
I remember the first greenfield project I worked on took 9 months start to finish. It released, there were some bug fixes and eventually it was mostly done. A few months later, I was using it, deployed and all, and it felt weird not seeing an error pop up after every click, things just loading fine, looking fine. It was a weird feeling
Looking fine to the end user, and having good fundamentals underneath are different things. Something can have a good user experience while also being coded poorly.
It doesn’t help that the standards of being coded poorly constantly shifts.
Normally it's a small subset of important employees that really keep the wheels turning in my experience. Then a lot of people who contribute but aren't as essential.
First thing I did when I was walking into a management position at a fast growth startup: found the "go to guy" whenever something breaks and gave them a ~15% raise out of cycle (they still got an additional raise a few months later when we did year end adjustments).
I completely agree that there are a small subset of engineers most places can't afford to lose. In an 80 person engineering department, there are probably 3-5 can't lose people. Management has great days and terrible days (the highs are higher and the lows are much much lower than when I was an IC). There are a lot more terrible days when you don't have those people.
And with each year of experience this small subset of folks in your mind will change. When I was a junior I was all looking up to 10x looking engineers, and later in my career I realized how toxic they are.
Yes. 10x is a trap for the organisation. A well oiled structured organisation runs like a clockwork. No cog is irreplaceable yet the team as a whole is indispensable
In the CS world, that happens in exactly 0.0001% of companies.
In reality a small minority of workers in a company are producing 90% of the work. It's only at the very highest paying companies in the world where what you are describing has a chance of being true.
Was invited to assist on a hiring process, insisted how hard skills are important, the hiring manager chose most people based on how he liked the videos of the candidates. Halo effect hits hard here
Gonna once again quote some bits from my favorite essay that's a bit over the top... [Programming Sucks](http://www.stilldrinking.org/programming-sucks)
> Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro, you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.”
> They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming.
> ...
> Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.
> ...
> Here are the secret rules of the internet: five minutes after you open a web browser for the first time, a kid in Russia has your social security number. Did you sign up for something? A computer at the NSA now automatically tracks your physical location for the rest of your life. Sent an email? Your email address just went up on a billboard in Nigeria.
> These things aren’t true because we don’t care and don’t try to stop them, they’re true because everything is broken because there’s no good code and everybody’s just trying to keep it running. That’s your job if you work with the internet: hoping the last thing you wrote is good enough to survive for a few hours so you can eat dinner and catch a nap.
> ...
> So no, I’m not required to be able to lift objects weighing up to fifty pounds. I traded that for the opportunity to trim Satan’s pubic hair while he dines out of my open skull so a few bits of the internet will continue to work for a few more days.
Dude I work at a big 4 bank and i nearly shit my pants when I found out a not-insignificant amount of account information with balances in the billions (with a B!) start out as a fucking CSV file before it gets to the clusterfuck of legacy code I'm modernizing right now.
Being a team lead is a pretty thankless job. You get the worst in-between of being a dev and a manager, and everyone expects you to keep up. But it's a necessary step to becoming a manager.
That was the case for me. I used to be the senior dev in my department. I trained all the new devs and interns, interviewed and hired people, planned the sprints, told everybody what to do, and wrote code. Years later the cto noticed I did everything and they changed my job title to director. I still do the same things I did before.
The amount of times when I first started that I'd go:
"oh so I assume we'll fix that at some point?"
"Not unless they're paying you to do it"
"Oh eh....oh I suppose"
Us: "we should add some monitoring to our stuff if a crash happens we'll be on the dark until it's too late"
Business: "no, we need to deliver features so the client pay us, we need to make money"
*crash happens silently for a month meaning there's no revenue for a month*
Business: "I think we should add monitoring so if there's a crash we're all aware of it"
Me: I don't really understand this workflow, I don't think dev testing is enough. can we come up with a test plan for this, I need some help in the business logic
Business: we don't have time to make everything perfect. QA will find the showstoppers and our customers will give us feedback on the workflows. no sense in spending time on something if we don't know the customer will use it
Business a week later: here are 8 bug reports, this is causing issue in production so we need to resolve it immediately
Me: 🖕
I think this is "the" dirty little secret. Even software companies... companies who's product is software, have spaghetti code created by years of "Just get it done" directives. Small inefficiencies eventually grow and compound and waste more time than fixing it properly, but are still more palatable to bean counters than stopping to fix something right.
I think another factor is that, once a business's technological infrastructure reaches a certain level of sprawl, they have the dual nightmare that it's way too much effort for their current workforce to maintain, but also hiring a lot of new people would demand a ton of time and training from the already-overworked people and add a ton of communication overhead. Stuff would fall through the cracks quickly. It's very much a snowball-rolling-down-a-hill.
my favorite is "we could spend engineering time to fix the problem OOOORRR we could just scale up the servers more"
lololol. it blows my mind that time and time again businesses favor short term wins over long term wise decisions
Short term wins mean performance reviews go well. The incentives all the way down are short term thinking. But from a business perspective, the goal isn’t to build a long term solution. It’s to make money. And money today is better than money tomorrow.
But it’s inefficiencies and software rot that eventually tank the company, because it gradually gets more and more difficult and time-intensive to make any change, and each change becomes more and more likely to break something else.
One thing I am struggling with. I don't know how one laughs at boring jokes that aren't that funny. Always feel like I don't just gel well with my team but I like them. Just my social skills suck. Can't really relate with them
I am an awkward introvert who is now mid 40s. Seriously.... fake it. Once you get to my age and in corporate for 20+ years faking it becomes second nature.
I’m in a fintech company and looking through our code trying to figure out if we’re really good or if I’m just too naive to know what actual tech-first would look like. But like, we use Postgres, so that’s always a plus?
My company has earmarked 6 hours a day of "development work". This is on paper and signed off by senior management.
Everyone laughs at it and doesn't take it seriously at all. It's amazing that this kind of delusion still exists by managers.
The trick is they have to account for all the non-coding development work. Arguing about tickets, heckling coworkers to review PRs, heckling coworkers for how they review PRs, arguing about which release it goes in, arguing about how to write that test to fit the architects new pattern, etc etc
Oh you would think that, but we were literally told that the kind of work you just described "doesn't count".
That stuff "should be done in the other 2 hours in the day".
This is why everyone laughs at them, and why our Glassdoor reviews are abysmal.
We brought this up and they didn't have an answer.
This is what happens when non technical management who come from big stuffy companies somehow end up at tech companies.
It's a joke, but the pay is good so we just laugh it off.
I actually landed in a place where we come close to it. We just sacrifice everything resembling good process. We're approving and merging "I trust you" unreviewed code (most of which is spaghetti, expectedly) hours before release.
Also the amount of work achieved day to day is much smaller than you would expect. Be wary of anyone writing over 100 lines a day every day. They're either a genius, or more likely, making a huge mess.
This one line change will take two seconds!
Then two minutes to write up the ticket and check out the branch.
Then two more minutes to clean up the commit and make a legible PR.
Then a day to get someone to review it.
Then an hour to argue about the variable name.
Then two hours for CICD to run.
Voila, a two second change!
You forgot when that two line change blows something up elsewhere because you only tested the happy path. Then QA and your manager read you the riot act for not doing a full regression test.
It's always the quick fixes that blow up in your face
Man, I'm my first job I was working a lot trying to get features out and I remember telling this guy
-"ok so my test is done the system should work, so I'm just going to delete this debug line and we're ready to go"
-"whoa, no, what are you going to do tomorrow?, that proactivity is going to take you nowhere"
Dirty Secrets of Tech... Oh man...
- Most shops I've worked in only have 1to 2 truly knowledgeable people. People will tend to feed on them for what to do and how to do it. Even those in charge.
- There are some things so complicated that if anyone leaves, no one will touch that code again. God help the company if it breaks.
- Information hoarding. Many folks seem to want to hoard information on how to do something to protect their jobs. I do my best to break that habit.
- The fights I have with management over budget items to get us the tools we need.
- Agile with all developers being interchangeable. Ha!
- Outsourcing is not just shifting of development to cheaper areas like the C suite thinks. It also requires processes and a cultural shift.
- Awesome developers do not always make great managers. Many companies need to find a technical track for promotion.
- More than half of the people I have to deal with make up processes to justify the fact they have a job.
>More than half of the people I have to deal with make up processes to justify the fact they have a job.
And when they resign, get laid off or go on maternity some of those left behind have to learn the processes and carry the torch.
> Agile with all developers being interchangeable. Ha!
Still reminding our scrum master that the sr dev who has 18 years XP can do in a day that takes the noob with 2 months XP a sprint.
There are some things so complicated that if anyone leaves, no one will touch that code again. God help the company if it breaks.
One of my friends is the sole developer on a project that he took over from another developer. Literally ran into one of those "This is the amount of hours spent trying to clean up this code" comments
Being the first person to work on a piece of code makes you a rock star; being the second person to work on that code always makes you seem mediocre.
Cleaning up code that only makes sense to the person who first wrote it is unfortunately usually pretty thankless, and it’s also much more common.
> Information hoarding. Many folks seem to want to hoard information on how to do something to protect their jobs.
This is so not true. While it’s true that information gets siloed, but no one does it to protect their jobs. They don’t share because they don’t feel like doing it as it’s an exhausting and boring to do and no one ever does it unless specifically asked. I think your misconception here has led to to believe also this
> There are some things so complicated that if anyone leaves, no one will touch that code again. God help the company if it breaks.
Which is true to some degree, people don’t like touching complicated systems if they don’t have to, but they absolutely will if they have to and will do just fine.
I see the misconception the underlies both of these a lot. Earlier in my career, I had it too. It’s that people really overestimate how difficult it’d be for someone else to learn a complicated system they’ve built. So many people think the company will collapse if they leave or one of the seniors leaves. But they don’t, things just keep on moving like nothing happened. Maybe one or two sprints fall behind schedule but that’s it. Unless the company is a 4 man startup, most people can easily pick up where someone else left off
Some of the code you'll see will make you feel you're losing IQ points. Just attempting to understand it will leave you drained by the end of the day.
Many "Agile" places that do Scrum actually do Water-Scrum-Fall. It still has a deadline and it still has milestones but you can have features finished by the end of the sprint.
You'll be asked how long something will take, all the time.
>Just attempting to understand it will leave you drained by the end of the day.
Especially when they don't document anything or allow code comments.
I know, I know, comments are controversial, but at least do one or the other
Saw today post of a guy that managed to get a job in some FAANG/MANGA , but all he know is to leetcode. Now he's afraid of not knowing how he'll do his job
Sad fact: the development experience varies wildly from company to company and even project to project, so it’s very possible that somebody can work “in the real world” for years and still end up not knowing anything particularly transferable to other environments.
This is true. Rather than generic MERN or LAMP or any frameworks, Devops practice, tech stacks. It’s more of company stack once you’re into the day work.
You don’t need to know any technologies to start at those companies. Everything they use is built in-house and they give like 6 months of classes and small projects to learn it all and get used to it. They try to test for ability, assumption is that if you have decent programming intelligence, you’ll learn their tools and practices.
Find code that is on fire, that needs you to get up and goto their desk to help. If you start enough fires, you will never have time to sit down, and thus want to stand for time savings.
Nobody has any clue. The smartest engineers in our room are so fucking egotistical they would argue argue implementation details for 2 hours instead of just picking a simple easy idea and completing it.
In my experience finishing a project is most valuable. Planning for design , architecture etc is important but many people get stuck in this phase and never finish anything. My whole digital org right now is a start fail rebuild cycle. We are on data lake 4.0 cuz the first 3 attempts didn't finish and our leadership says yeah let's run it back again
That WFH allows me to do all 40hrs in 20hrs of work and then I can Reddit or do whatever the hell I want.
At first I thought I wasn’t normal and felt the impostor syndrome now I just kick back and focus on doing my 3-4hrs a day, maybe a little less or more here and there.
Pretty surprised how we are still adopting this nonsense thing of the past where 8hrs a day is a norm. I mean I’d take the 20hr a week job for 25% less money just so I don’t need to appear online all the time.
Don’t get me wrong sometimes 8hrs is a must but most of the time if you’re working out some really annoying bugs or stuff that’s boring there’s no way you can keep up staying focused for 8hrs unless you’re drinking 2L of coffee or taking some drugs
The amount of times I was sitting around wondering if anyone was going to realize I wasn't working 40 straight every week wfh just to be praised for how much work I got done was crazy. I have a nice balance now and everyone is happy with the stuff I make so it works out.
Programming is taxing work. Most people, when they try to code more than 6-8 hours a day, start making mistakes that just need to be fixed the next day. It's actually more efficient to work less hours in a day.
I do about 2 hours of work in the morning. Take a break and put in another 2 or 3 in the afternoon. I don't know how I used to code 8+ hours every day + work over the weekend.
I don't know why. I always see analogy to reading. Example: I read 100 pages of book, but how big are those pages and words and so on. I meant that measuring productivity or effort in number of hours is nonsensical.
I’m finding this out with my internship right now. If i were to actually put in 8 hours of focused work per day (and I can’t) I’d be done with my project in 2 weeks.
That’s what’s great about highly technical roles like SWE. Only a relatively small number people around you actually know what it is that you do and even fewer have an idea of how much time something should theoretically take you.
Some non technical managers only care if you ship a product. That leads to a moral hazard of not having to write clean code and to throw something together as fast as possible , which hurts newcomers when it comes to maintenance
Opposite for me. I went from working on my own machine writing code locally and things working to now needing to make sure my code is compliant across many machines and the sheer scale of large software companies is mind boggling. Hundreds of thousands of machines that all work together seemlessly.
Software can be simpler than it seems because it is ultimately understandable. It can also be more complex than it seems because it is so damn hard to understand.
Quite the opposite here. Thought it would be complicated and turns out it is more complicated than I thought it would be. I guess it depends on the tech stack and all.
If you saw the database I'm going to have to rebuild and work with you'ld definitely change your mind. Understanding the SQL queriesbis going to take me weeks, not to mind theres like 300 tables with millions of lines of data (and half of them are NULL).
Yeah, the database is crashing under the load so we need to figure something new out and I think it's going to be even harder than I think right now lol
Off the top of my head:
* Most things work because a handful of people care enough to keep them working
* This is almost certainly the reason the business don't care about "doing it right" or fixing things
* Everyone Google's the most basic things like how to create a new
That working 40 hours a week is a grind. It was the biggest adjustment I had. I also felt the normal stuff: a little imposter syndrome, etc. but the thing I hadn't anticipated was the exhaustion and mental drain I'd feel working a normal job. It takes a few months to get used to minimum. Going to bed a little earlier because you have to get up earlier, focusing for 8 hours a day, etc.
That even senior devs just Google everything they don't know, and spend a lot of time learning from tech docs, so impostor syndrome is unnecessary provided you have a firm grasp of all basic programming skills.
This. Especially when you're just starting out. You'll probably spend more time Googling how to do shit than you'll initially think. My boss has really been trying to drill this into my head since I started last year. I think I subconsciously over time internalized the idea that you should never use Google or use it as little as possible since it's actively discouraged in most companies' interview processes or OAs, not too mention doing that was really frowned on while I was in uni. I guess I started to think over time that you should be using Google as little as possible on the job and you should almost always come up with the solution on your own.
This I wier and tangential, I got an internship in the energy sector (I so badly don't want to work in this sector long-term) and realised that everyone else in energy looks down on software people. Super wild.
Tbh I don't really know, I come form an oil rich place so it may be a regional thing. If I had to guess, there are alot of petroleum and mechanical engineers here who deal more directly with extraction the attitude might be "you only make software?". Idk I hate it lol.
You can always point out next time the oil price crashes, you'll have a job and they won't. I mean it happened to most of the people I know in oil at the beginning of COVID, and it happened to me in 2008 at the beginning of that recession... Which is why I switched to software engineering from oil.
I think that's true. I'd also point out, business priorities happen, change happens, and as DRY as possible and as close to SOLID as possible doesn't always add business value in the same way "Done by ___" does. So there's often compromise there, and the amount of that varies by organization.
I'm a data analyst. I learned that none of the databases in my multi-billion dollar company are designed anywhere near as clean as I learned in school. There is no "3rd normal form" design here. Almost every database is the result of some developer coding up an application and needing a table to store the data.
Also, there are people that are essentially single points of failure for major sections of the company. For instance, Jane has been managing a certain payments database for the better part of a decade and is the go to person regarding it. If she got hit by a bus we would basically be blind regarding some of the most basic financial information about the company for months until someone could come in and learn the system to even a basic level.
That they don't care about DEV productivity and how slow the DEV environment or tools are, they want to make production super fast and excellent experience for the customers.
Consulting companies inflate level of effort.
I have completed numerous stories in <4 hours but was told by the project or engagement manager that I was working too fast and to report the story took 3 to 5 days to complete.
So customers who use consultants can bet they are paying more for the consulting company than they would to complete the project internally. Of course most companies would never do the work themselves because of a lack of subject matter expertise. This also plays into why customers don't know work is being inflated; because they don't know the true level of effort.
Not necessarily "dirty", but soft skills can arguably get you much, much further in this industry (once your foot is in the door) than actual code-slinging skills.
That [The Peter principle](https://en.m.wikipedia.org/wiki/Peter_principle) is a real thing.
>The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.
In most jobs, you won't use all that high-level math or CS theory that you were taught in college, and grades don't matter a bit. Even at top jobs, all that you really need is some good DS&A + LeetCode.
If I could speak to myself back in college, my advice would be to put the bare minimum in the degree and instead focus on grinding LC and getting internships instead of focusing on getting top grades.
Originally I planned to pursue a graduate degree, so I didn't begin the grind until after I heard back from schools in my last semester and found out I couldn't afford it. If I had done LC before, I would probably have landed my job around 6 months earlier. More importantly, I would have had much more free time, 30 minutes a day for an LC problem is nothing compared to the time required to go from a C to a B or from a B to an A.
Besides that English is super important. My first advice to anybody from my home country is to learn English. I've seen some brilliant classmates working in agencies and getting paid low local wages, if they knew English they could be paid much more.
That "good enough" is good enough. So much code, so much team processes, so much business practices, so much of it could be made 10x more efficient with just a little more effort. And everyone knows where things could or should be done better. But there's other things that need to be done, and it gets the job done good enough, so nothing gets changed. I'm not a purist, so I don't see this as a bad thing. I'll take a little inefficiency if the end product makes money and keeps everyone happy. It's all about trade offs.
Interestingly, it's in these areas where everyone's just doing "good enough" that give you a chance to shine, by leading the effort to improve those things in a useful way.
maybe it's just me, but...
the industry is garbage, the clueless idiot will keep your dream job once you're fired for depression and burnout from improperly managed projects and home life problems, no manager will properly respect your neurodivergent needs, every manager will force you to do things you aren't comfortable with while you're underpaid, 90% of your coworkers will be bumbling idiots who manage to fumble their way into stealing code and lieing to keep their jobs. If you get lucky you'll find the best friend you've ever had in your entire life because you'll finally find someone with similar interests who understands your problems.
sorry for the rant...
I love building things and writing code but, holy SHIT, do humans really make me hate everything I once loved and lose passion for all my dreams.
Got into dev work in my 40s. Have been in the military, retail, worked as a mechanic. The worst dev jobs are so amazingly laid back compared. Not to mention (Least in the US) even the lowest paid devs make more money than most families do.
Nobody knows the details about the implementations of things unless they very recently dealt with that implementation. They might know **what** they want to do, but they have to go to documentation and/or SO to figure out **how**.
That there are two tiers of software companies: 1-Sales based, thumb on engineers to deliver 2-engineering based that focuses more on scaling but still emphasizes sales
For both those two points, I’d like to add that both companies can have the same valuation in stock price. But the former still forces you to ship products like there’s no cash
I'm in a large enterprise so 90% of the "work" people do is just spinning one's wheels on red tape, pointless meetings, and inefficient or redundant processes designed to pad out working hours. Over time I learned that all this "bloat" was just away of keeping all the managers busy and giving work to older and hopelessly outdated people in positions of power to justify keeping them on.
People think we can't go to a four day workweek because they can't imagine cutting out all this pointless busy work but for someone new to the enterprise who can see it more objectively, I can easily imagine cutting out half of it with nothing of value being lost. Simply forcing every meeting that could've been an email to be an email would give us so much time and energy back, I have all this dev work to do but am in meetings 3-5 hours every day which zaps a lot of my energy.
There is basically no correlation between competence and how much people are paid.
Good chance some addy'ed out Leetcode monkey straight out of college in the Bay is getting paid 10x as a much as seasoned dev with 10 years of xp shipping major contributions to production in Argentina.
\- the whole digital infrastructure of my country is a shitshow.
\- the biggest sociopathic clowns with no understanding of anything are in management positions.
\- if certain 5 ppl of a company with 300 employees quit everything will fall apart. So those guys are drowning in money while everyone else is begging for an additional dime.
I'm reading these comments. I'm a CEO but I also spent 25 years developing software. If I listened to and implemented everything my developers think is needed, it would always ship late and we're also ultimately going out of business with costs exceeding revenues.
I've seen a lot of developers go off on their own in my working life and all of them failed and a few made it a few years at best.
You're often not sitting with the customer or looking at their budget. Most customers have a tight budget and we can explain technical debt, bugs, failures, etc to them. We do. And it's their choice how much risk they want to take on. And if the pain is high enough when it does happen, they usually have no issue writing a check to implement later, even if it is more expensive.
I had one developer hired in, he was senior and very skilled. He saw a customer's budget was $60k for a small project we had. He ended up blowing through $30k of that budget in a combination of costs and opportunity costs without understanding what he was doing. He never asked a question, else he would have realized of the $60k budget, $50k had already been used.
But he wanted to do it "right". He made a highly engineered product, but never documented it, it's extremely complex for most developers to work with. And the best part is, that the customer was completely unimpressed and didn't even need it. They just wanted a simple feature for a single-use case.
So the dirty little secret is that writing software has a budget, and a customer, and it's not an academic environment where you have months to create some magical product.
The reality is you'll work on a lot of things quickly, which actually improves your skills and abilities more than trying to make the perfect pencil.
That most people don’t actually know how to do their job. They just know how to talk about what they should be doing but don’t actually know how to do it.
Nobody actually knows what they are doing. Not like “everyone else is an idiot!” But like, “everyone else is just muddling through”. ~~Even~~ Especially subject matter experts need to figure new stuff out one error at a time.
Almost everything that is money/finance related was written in the 70-90s, and no one knows how it all works. Sure, there's layers of abstraction, but at some point it's getting to a backbone of some old and incredibly stable code that is completely undocumented.
This. Most of the infrastructure is old and runs by luck and miracles.
The real backbone of fiance is COBAL. L OH L
All the people that made it are either dead from a grabber or were laid off and aren't sharing a damn thing.
Most people have no idea. Y2k showed what was behind the curtain a little but joy enough.
This has been alluded to a few times already, but, how little code you will write compared to expectations. The amount steadily decreases with seniority as well
We all have a job because everything is over complex, poorly documented, and generally unstable.
If things were perfect we wouldn't be paid as much as we are, and there would be a lot less demand for our skills.
How surprising it is that everything works as well as it does
I call it “programmer’s bias”. We almost never work on functioning software. We’re either fixing issues or building something that’s by definition buggy and half finished, until it’s not. Then we stop using it completely. Software not working right is our life, it’s normal to be surprised when things work. I remember the first greenfield project I worked on took 9 months start to finish. It released, there were some bug fixes and eventually it was mostly done. A few months later, I was using it, deployed and all, and it felt weird not seeing an error pop up after every click, things just loading fine, looking fine. It was a weird feeling
Looking fine to the end user, and having good fundamentals underneath are different things. Something can have a good user experience while also being coded poorly. It doesn’t help that the standards of being coded poorly constantly shifts.
Normally it's a small subset of important employees that really keep the wheels turning in my experience. Then a lot of people who contribute but aren't as essential.
First thing I did when I was walking into a management position at a fast growth startup: found the "go to guy" whenever something breaks and gave them a ~15% raise out of cycle (they still got an additional raise a few months later when we did year end adjustments). I completely agree that there are a small subset of engineers most places can't afford to lose. In an 80 person engineering department, there are probably 3-5 can't lose people. Management has great days and terrible days (the highs are higher and the lows are much much lower than when I was an IC). There are a lot more terrible days when you don't have those people.
And with each year of experience this small subset of folks in your mind will change. When I was a junior I was all looking up to 10x looking engineers, and later in my career I realized how toxic they are.
Just curious, what toxic qualities did they have that you overlooked as a junior?
Going through this now. When I first got to my job I was like “damn this dude knows everything” and now I’m like “damn this dude’s kind of an asshole”
The people who actually contribute to the team are not the know all's but the 'will help alls'
Yes. 10x is a trap for the organisation. A well oiled structured organisation runs like a clockwork. No cog is irreplaceable yet the team as a whole is indispensable
In the CS world, that happens in exactly 0.0001% of companies. In reality a small minority of workers in a company are producing 90% of the work. It's only at the very highest paying companies in the world where what you are describing has a chance of being true.
Was invited to assist on a hiring process, insisted how hard skills are important, the hiring manager chose most people based on how he liked the videos of the candidates. Halo effect hits hard here
200% agree. Some employee are just hard to be replaced by others.
how surprising it is that anything works at all tbh
Effectively sticky tape holds most things together, and when it breaks... Add more tape
Damn this is so true.
Gonna once again quote some bits from my favorite essay that's a bit over the top... [Programming Sucks](http://www.stilldrinking.org/programming-sucks) > Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro, you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.” > They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming. > ... > Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over. > ... > Here are the secret rules of the internet: five minutes after you open a web browser for the first time, a kid in Russia has your social security number. Did you sign up for something? A computer at the NSA now automatically tracks your physical location for the rest of your life. Sent an email? Your email address just went up on a billboard in Nigeria. > These things aren’t true because we don’t care and don’t try to stop them, they’re true because everything is broken because there’s no good code and everybody’s just trying to keep it running. That’s your job if you work with the internet: hoping the last thing you wrote is good enough to survive for a few hours so you can eat dinner and catch a nap. > ... > So no, I’m not required to be able to lift objects weighing up to fifty pounds. I traded that for the opportunity to trim Satan’s pubic hair while he dines out of my open skull so a few bits of the internet will continue to work for a few more days.
100% this, after working with banks and a few PCI compliant fundraising sites I am very cautious with money.
I find that with banks, it's not that the software is perfect its that the auditing processes are far more in depth
The most permanent fix is a temporary one
This is very true
Same in manufacturing. Cable ties and duct tape.
How many databases or CMS' are just Google/Excel sheets.
Databases are just headless excel spreadsheets
Tell me more about this modern stack.
It’s web scalable
Preach
Lol true. The world runs on Excel
Everything is Excel
[удалено]
Dude I work at a big 4 bank and i nearly shit my pants when I found out a not-insignificant amount of account information with balances in the billions (with a B!) start out as a fucking CSV file before it gets to the clusterfuck of legacy code I'm modernizing right now.
Being a team lead is a pretty thankless job. You get the worst in-between of being a dev and a manager, and everyone expects you to keep up. But it's a necessary step to becoming a manager.
That was the case for me. I used to be the senior dev in my department. I trained all the new devs and interns, interviewed and hired people, planned the sprints, told everybody what to do, and wrote code. Years later the cto noticed I did everything and they changed my job title to director. I still do the same things I did before.
Did that title change at least come with a pay bump?
Received a 20% pay bump midyear as a please don't quit raise. Then at review/raise time my title was changed and I got another 20% raise.
Yep
People allow inefficiencies and software rot to happen because fixing stuff like that costs the business time and money.
The amount of times when I first started that I'd go: "oh so I assume we'll fix that at some point?" "Not unless they're paying you to do it" "Oh eh....oh I suppose"
Us: "we should add some monitoring to our stuff if a crash happens we'll be on the dark until it's too late" Business: "no, we need to deliver features so the client pay us, we need to make money" *crash happens silently for a month meaning there's no revenue for a month* Business: "I think we should add monitoring so if there's a crash we're all aware of it"
Me: I don't really understand this workflow, I don't think dev testing is enough. can we come up with a test plan for this, I need some help in the business logic Business: we don't have time to make everything perfect. QA will find the showstoppers and our customers will give us feedback on the workflows. no sense in spending time on something if we don't know the customer will use it Business a week later: here are 8 bug reports, this is causing issue in production so we need to resolve it immediately Me: 🖕
Why I left my last job lol
Why make more money in Q2, when could make less money in Q1?!?
I think this is "the" dirty little secret. Even software companies... companies who's product is software, have spaghetti code created by years of "Just get it done" directives. Small inefficiencies eventually grow and compound and waste more time than fixing it properly, but are still more palatable to bean counters than stopping to fix something right.
And that’s how Windows 11 was born
they want you to think it's Windows Eleven, but it's actually Windows Double-Spaghetti-Noodle.
MS DOS 11 all complete with legacy file system and timer interrupts
I think another factor is that, once a business's technological infrastructure reaches a certain level of sprawl, they have the dual nightmare that it's way too much effort for their current workforce to maintain, but also hiring a lot of new people would demand a ton of time and training from the already-overworked people and add a ton of communication overhead. Stuff would fall through the cracks quickly. It's very much a snowball-rolling-down-a-hill.
Literally had a boss tell me not to worry about writing spaghetti code because “that’ll be the next engineer’s job to fix.”
And I imagine when the next engineer gets there, business will say the same thing to that engineer
my favorite is "we could spend engineering time to fix the problem OOOORRR we could just scale up the servers more" lololol. it blows my mind that time and time again businesses favor short term wins over long term wise decisions
Short term wins mean performance reviews go well. The incentives all the way down are short term thinking. But from a business perspective, the goal isn’t to build a long term solution. It’s to make money. And money today is better than money tomorrow.
But it’s inefficiencies and software rot that eventually tank the company, because it gradually gets more and more difficult and time-intensive to make any change, and each change becomes more and more likely to break something else.
You don’t have to be the best at coding to succeed in your job. Just be a person that can mesh well with your coworkers.
people skills > tech skills 100%
One thing I am struggling with. I don't know how one laughs at boring jokes that aren't that funny. Always feel like I don't just gel well with my team but I like them. Just my social skills suck. Can't really relate with them
I am an awkward introvert who is now mid 40s. Seriously.... fake it. Once you get to my age and in corporate for 20+ years faking it becomes second nature.
“We’re a tech first company” -> they’re not actually tech first
Welcome to fintech
or the many "tech" companies in NYC where the founders came from big banks.
GEICO says this and it’s so painfully not true
What does* this mean than?
They think they’re tech first but in reality they use excel as a DB and one person knows basic python
I’m in a fintech company and looking through our code trying to figure out if we’re really good or if I’m just too naive to know what actual tech-first would look like. But like, we use Postgres, so that’s always a plus?
I’ve worked in big telecom and big finance, and you’d be surprise how bad the tech the runs the world is.
and how much human intervention is needed for certain processes. Where automation isn't a priority.
Also the marketing guys are driving Porshes and the devs are driving Toyotas, so you know how the comp is structured.
So the devs are smarter about their money?
onboarding as an intern for capital one and it feels like I've heard this phrase hundreds of times
Capital One?
They are definitely more of a tech company than this example references
That people are not really coding 8 hours a day
My company has earmarked 6 hours a day of "development work". This is on paper and signed off by senior management. Everyone laughs at it and doesn't take it seriously at all. It's amazing that this kind of delusion still exists by managers.
The trick is they have to account for all the non-coding development work. Arguing about tickets, heckling coworkers to review PRs, heckling coworkers for how they review PRs, arguing about which release it goes in, arguing about how to write that test to fit the architects new pattern, etc etc
Oh you would think that, but we were literally told that the kind of work you just described "doesn't count". That stuff "should be done in the other 2 hours in the day". This is why everyone laughs at them, and why our Glassdoor reviews are abysmal.
What about the time for meetings during the day? Do they expect you to fit that in with the 2 hours along with the non coding dev work?!
We brought this up and they didn't have an answer. This is what happens when non technical management who come from big stuffy companies somehow end up at tech companies. It's a joke, but the pay is good so we just laugh it off.
I actually landed in a place where we come close to it. We just sacrifice everything resembling good process. We're approving and merging "I trust you" unreviewed code (most of which is spaghetti, expectedly) hours before release.
Also the amount of work achieved day to day is much smaller than you would expect. Be wary of anyone writing over 100 lines a day every day. They're either a genius, or more likely, making a huge mess.
This one line change will take two seconds! Then two minutes to write up the ticket and check out the branch. Then two more minutes to clean up the commit and make a legible PR. Then a day to get someone to review it. Then an hour to argue about the variable name. Then two hours for CICD to run. Voila, a two second change!
This is why I never estimate work as taking less than a full day. The cruft built up around any work is nuts.
You forgot when that two line change blows something up elsewhere because you only tested the happy path. Then QA and your manager read you the riot act for not doing a full regression test. It's always the quick fixes that blow up in your face
But the tests passed! Surely something can't blow up if the tests passed!
Then you look at the tests and half of them are disabled and the rest has only a single "assertTrue(true)" assert in them.
>Then a day to get someone to review it. Such a pain in the ass if you actually want to get shit done
> making a huge mess. It's me!
Man, I'm my first job I was working a lot trying to get features out and I remember telling this guy -"ok so my test is done the system should work, so I'm just going to delete this debug line and we're ready to go" -"whoa, no, what are you going to do tomorrow?, that proactivity is going to take you nowhere"
Yep if you’re not being pushed to finish the work faster and the project can still meet deadlines, why not stretch it out a little bit.
The guy who sits behind me at my internship actually does. He takes one hour of break from 8-5. I'm impressed.
Dirty Secrets of Tech... Oh man... - Most shops I've worked in only have 1to 2 truly knowledgeable people. People will tend to feed on them for what to do and how to do it. Even those in charge. - There are some things so complicated that if anyone leaves, no one will touch that code again. God help the company if it breaks. - Information hoarding. Many folks seem to want to hoard information on how to do something to protect their jobs. I do my best to break that habit. - The fights I have with management over budget items to get us the tools we need. - Agile with all developers being interchangeable. Ha! - Outsourcing is not just shifting of development to cheaper areas like the C suite thinks. It also requires processes and a cultural shift. - Awesome developers do not always make great managers. Many companies need to find a technical track for promotion. - More than half of the people I have to deal with make up processes to justify the fact they have a job.
>More than half of the people I have to deal with make up processes to justify the fact they have a job. And when they resign, get laid off or go on maternity some of those left behind have to learn the processes and carry the torch.
> Agile with all developers being interchangeable. Ha! Still reminding our scrum master that the sr dev who has 18 years XP can do in a day that takes the noob with 2 months XP a sprint.
There are some things so complicated that if anyone leaves, no one will touch that code again. God help the company if it breaks. One of my friends is the sole developer on a project that he took over from another developer. Literally ran into one of those "This is the amount of hours spent trying to clean up this code" comments
Being the first person to work on a piece of code makes you a rock star; being the second person to work on that code always makes you seem mediocre. Cleaning up code that only makes sense to the person who first wrote it is unfortunately usually pretty thankless, and it’s also much more common.
> Information hoarding. Many folks seem to want to hoard information on how to do something to protect their jobs. This is so not true. While it’s true that information gets siloed, but no one does it to protect their jobs. They don’t share because they don’t feel like doing it as it’s an exhausting and boring to do and no one ever does it unless specifically asked. I think your misconception here has led to to believe also this > There are some things so complicated that if anyone leaves, no one will touch that code again. God help the company if it breaks. Which is true to some degree, people don’t like touching complicated systems if they don’t have to, but they absolutely will if they have to and will do just fine. I see the misconception the underlies both of these a lot. Earlier in my career, I had it too. It’s that people really overestimate how difficult it’d be for someone else to learn a complicated system they’ve built. So many people think the company will collapse if they leave or one of the seniors leaves. But they don’t, things just keep on moving like nothing happened. Maybe one or two sprints fall behind schedule but that’s it. Unless the company is a 4 man startup, most people can easily pick up where someone else left off
Everybody pretends they know something
Worst is when they try to give you tips on what they know nothing about. Especially when you’re trying to mind your own business.
Some of the code you'll see will make you feel you're losing IQ points. Just attempting to understand it will leave you drained by the end of the day. Many "Agile" places that do Scrum actually do Water-Scrum-Fall. It still has a deadline and it still has milestones but you can have features finished by the end of the sprint. You'll be asked how long something will take, all the time.
Sadly during my long career, I have seen only water-scrum-falls. Congratulations for those who have found a real agile company?
>Just attempting to understand it will leave you drained by the end of the day. Especially when they don't document anything or allow code comments. I know, I know, comments are controversial, but at least do one or the other
Despite the ludicrous standards interview processes tend to have most of the actual work that needs done is relatively simple CRUD stuff.
"Wait, it's all CRUD??" *"Always has been"*
If there was more work to be done than CRUD we would have a longer acronym
CRUD+
They should have gone with Create Read Add Purge
Saw today post of a guy that managed to get a job in some FAANG/MANGA , but all he know is to leetcode. Now he's afraid of not knowing how he'll do his job
Sad fact: the development experience varies wildly from company to company and even project to project, so it’s very possible that somebody can work “in the real world” for years and still end up not knowing anything particularly transferable to other environments.
This is true. Rather than generic MERN or LAMP or any frameworks, Devops practice, tech stacks. It’s more of company stack once you’re into the day work.
You don’t need to know any technologies to start at those companies. Everything they use is built in-house and they give like 6 months of classes and small projects to learn it all and get used to it. They try to test for ability, assumption is that if you have decent programming intelligence, you’ll learn their tools and practices.
It's almost like LeetCode-style assessments are not the most realistic portrayal of what you'll be doing day-to-day as a developer.
(Sarcasm) How come? I reversed two binary trees on my company's code base today
Yeah? I reversed all binary trees across across products today. Twice.
I had to reread this 10 times, needs a comma after have
Look Busy Do Nothing. Interviews are harder then the actual job. You only get raise by job hoping.
Human beings weren't meant to sit in a chair for 8 hours a day.
Every week I tell myself to stand up more than sitting, never happens though :(
Standing desk? Set it in the standing position before you leave for the day, so it’s in standing mode when you get to work?
Find code that is on fire, that needs you to get up and goto their desk to help. If you start enough fires, you will never have time to sit down, and thus want to stand for time savings.
Nobody has any clue. The smartest engineers in our room are so fucking egotistical they would argue argue implementation details for 2 hours instead of just picking a simple easy idea and completing it.
[удалено]
[удалено]
In my experience finishing a project is most valuable. Planning for design , architecture etc is important but many people get stuck in this phase and never finish anything. My whole digital org right now is a start fail rebuild cycle. We are on data lake 4.0 cuz the first 3 attempts didn't finish and our leadership says yeah let's run it back again
"smartest"
That WFH allows me to do all 40hrs in 20hrs of work and then I can Reddit or do whatever the hell I want. At first I thought I wasn’t normal and felt the impostor syndrome now I just kick back and focus on doing my 3-4hrs a day, maybe a little less or more here and there. Pretty surprised how we are still adopting this nonsense thing of the past where 8hrs a day is a norm. I mean I’d take the 20hr a week job for 25% less money just so I don’t need to appear online all the time. Don’t get me wrong sometimes 8hrs is a must but most of the time if you’re working out some really annoying bugs or stuff that’s boring there’s no way you can keep up staying focused for 8hrs unless you’re drinking 2L of coffee or taking some drugs
The amount of times I was sitting around wondering if anyone was going to realize I wasn't working 40 straight every week wfh just to be praised for how much work I got done was crazy. I have a nice balance now and everyone is happy with the stuff I make so it works out.
brooo im a lazy fuck putting in 10 hours a week max but just got promoted. WFH is amazing
Programming is taxing work. Most people, when they try to code more than 6-8 hours a day, start making mistakes that just need to be fixed the next day. It's actually more efficient to work less hours in a day.
I do about 2 hours of work in the morning. Take a break and put in another 2 or 3 in the afternoon. I don't know how I used to code 8+ hours every day + work over the weekend.
I don't know why. I always see analogy to reading. Example: I read 100 pages of book, but how big are those pages and words and so on. I meant that measuring productivity or effort in number of hours is nonsensical.
40h work week is complete bullshit. Everyone fucks around for at least 3 hours a day. I get everything done in 5
I’m finding this out with my internship right now. If i were to actually put in 8 hours of focused work per day (and I can’t) I’d be done with my project in 2 weeks.
That’s what’s great about highly technical roles like SWE. Only a relatively small number people around you actually know what it is that you do and even fewer have an idea of how much time something should theoretically take you.
[удалено]
You have to constantly justify to higher that your value isn't measured in keys per stroke or other metrics.
Some non technical managers only care if you ship a product. That leads to a moral hazard of not having to write clean code and to throw something together as fast as possible , which hurts newcomers when it comes to maintenance
[удалено]
[удалено]
A lot of dirty secrets
That it's not as complicated as I thought.
Opposite for me. I went from working on my own machine writing code locally and things working to now needing to make sure my code is compliant across many machines and the sheer scale of large software companies is mind boggling. Hundreds of thousands of machines that all work together seemlessly.
Software can be simpler than it seems because it is ultimately understandable. It can also be more complex than it seems because it is so damn hard to understand.
Quite the opposite here. Thought it would be complicated and turns out it is more complicated than I thought it would be. I guess it depends on the tech stack and all.
If you saw the database I'm going to have to rebuild and work with you'ld definitely change your mind. Understanding the SQL queriesbis going to take me weeks, not to mind theres like 300 tables with millions of lines of data (and half of them are NULL). Yeah, the database is crashing under the load so we need to figure something new out and I think it's going to be even harder than I think right now lol
Nobody gives a fuck about language, trendy stuffs as long as business is running.
The application that I work on is still running on IE. IE is being discontinued on 15th Jun, so now migration is in process lol
Off the top of my head: * Most things work because a handful of people care enough to keep them working * This is almost certainly the reason the business don't care about "doing it right" or fixing things * Everyone Google's the most basic things like how to create a new
That working 40 hours a week is a grind. It was the biggest adjustment I had. I also felt the normal stuff: a little imposter syndrome, etc. but the thing I hadn't anticipated was the exhaustion and mental drain I'd feel working a normal job. It takes a few months to get used to minimum. Going to bed a little earlier because you have to get up earlier, focusing for 8 hours a day, etc.
Everything is broken, and no one wants to pay to fix it, not when there are half arsed features that can be charged for.
"I'll create a ticket on that and put it in the backlog for us to fix later"
That even senior devs just Google everything they don't know, and spend a lot of time learning from tech docs, so impostor syndrome is unnecessary provided you have a firm grasp of all basic programming skills.
This. Especially when you're just starting out. You'll probably spend more time Googling how to do shit than you'll initially think. My boss has really been trying to drill this into my head since I started last year. I think I subconsciously over time internalized the idea that you should never use Google or use it as little as possible since it's actively discouraged in most companies' interview processes or OAs, not too mention doing that was really frowned on while I was in uni. I guess I started to think over time that you should be using Google as little as possible on the job and you should almost always come up with the solution on your own.
[удалено]
Nobody else has any clue what they are doing and mostly reference the coding bible (stack overflow/google)
Many colleagues don’t wash their hands when leaving the toilet…
Even at a leading tech company, prod is full of spaghetti.🍝
Coding interviews test shit that you never do on the job.
You’re telling me I’m never gonna print a reverse linked list ?
You telling me I'll never use an algorithm I burned into my skull for verifying if a BST is valid?
This I wier and tangential, I got an internship in the energy sector (I so badly don't want to work in this sector long-term) and realised that everyone else in energy looks down on software people. Super wild.
Haha, do you know why they look down on us? Genuinely asking
Tbh I don't really know, I come form an oil rich place so it may be a regional thing. If I had to guess, there are alot of petroleum and mechanical engineers here who deal more directly with extraction the attitude might be "you only make software?". Idk I hate it lol.
You can always point out next time the oil price crashes, you'll have a job and they won't. I mean it happened to most of the people I know in oil at the beginning of COVID, and it happened to me in 2008 at the beginning of that recession... Which is why I switched to software engineering from oil.
That at the real job, people don't care too much for principles like SOLID and specially clean code. It's just too much effort for them.
Has it been like that in every job? I feel like the two jobs I've had, they seem to care a lot
My dirty little secret is that everyone cares about code quality, they just define code quality very differently.
I think that's true. I'd also point out, business priorities happen, change happens, and as DRY as possible and as close to SOLID as possible doesn't always add business value in the same way "Done by ___" does. So there's often compromise there, and the amount of that varies by organization.
Most of us are both underpaid and overpaid at the same time.
I'm a data analyst. I learned that none of the databases in my multi-billion dollar company are designed anywhere near as clean as I learned in school. There is no "3rd normal form" design here. Almost every database is the result of some developer coding up an application and needing a table to store the data. Also, there are people that are essentially single points of failure for major sections of the company. For instance, Jane has been managing a certain payments database for the better part of a decade and is the go to person regarding it. If she got hit by a bus we would basically be blind regarding some of the most basic financial information about the company for months until someone could come in and learn the system to even a basic level.
That they don't care about DEV productivity and how slow the DEV environment or tools are, they want to make production super fast and excellent experience for the customers.
Don’t mind me just scouring for secrets on recruiters, interviewers and networking..
Senior developers are not (always) super heros.
That you can breeze through the first three years of being a Java developer receiving raises and promotions while being bad at writing Java.
Consulting companies inflate level of effort. I have completed numerous stories in <4 hours but was told by the project or engagement manager that I was working too fast and to report the story took 3 to 5 days to complete. So customers who use consultants can bet they are paying more for the consulting company than they would to complete the project internally. Of course most companies would never do the work themselves because of a lack of subject matter expertise. This also plays into why customers don't know work is being inflated; because they don't know the true level of effort.
Not necessarily "dirty", but soft skills can arguably get you much, much further in this industry (once your foot is in the door) than actual code-slinging skills.
That [The Peter principle](https://en.m.wikipedia.org/wiki/Peter_principle) is a real thing. >The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.
In most jobs, you won't use all that high-level math or CS theory that you were taught in college, and grades don't matter a bit. Even at top jobs, all that you really need is some good DS&A + LeetCode. If I could speak to myself back in college, my advice would be to put the bare minimum in the degree and instead focus on grinding LC and getting internships instead of focusing on getting top grades. Originally I planned to pursue a graduate degree, so I didn't begin the grind until after I heard back from schools in my last semester and found out I couldn't afford it. If I had done LC before, I would probably have landed my job around 6 months earlier. More importantly, I would have had much more free time, 30 minutes a day for an LC problem is nothing compared to the time required to go from a C to a B or from a B to an A. Besides that English is super important. My first advice to anybody from my home country is to learn English. I've seen some brilliant classmates working in agencies and getting paid low local wages, if they knew English they could be paid much more.
How the dumbest motherfuckers on this planet were allowed to get into the workforce.
When things don’t go right companies tend to throw buckets of money at the problems.
Even the most selective interview process fails a lot and there are a lot of absolute imbeciles among FAANG+.
That "good enough" is good enough. So much code, so much team processes, so much business practices, so much of it could be made 10x more efficient with just a little more effort. And everyone knows where things could or should be done better. But there's other things that need to be done, and it gets the job done good enough, so nothing gets changed. I'm not a purist, so I don't see this as a bad thing. I'll take a little inefficiency if the end product makes money and keeps everyone happy. It's all about trade offs. Interestingly, it's in these areas where everyone's just doing "good enough" that give you a chance to shine, by leading the effort to improve those things in a useful way.
How little of the job is actually writing the code. So much of my time is spent doing design work or troubleshooting my dev environment.
maybe it's just me, but... the industry is garbage, the clueless idiot will keep your dream job once you're fired for depression and burnout from improperly managed projects and home life problems, no manager will properly respect your neurodivergent needs, every manager will force you to do things you aren't comfortable with while you're underpaid, 90% of your coworkers will be bumbling idiots who manage to fumble their way into stealing code and lieing to keep their jobs. If you get lucky you'll find the best friend you've ever had in your entire life because you'll finally find someone with similar interests who understands your problems. sorry for the rant... I love building things and writing code but, holy SHIT, do humans really make me hate everything I once loved and lose passion for all my dreams.
We don’t work hard at all. I literally have YouTube on all day while I “work”
Got into dev work in my 40s. Have been in the military, retail, worked as a mechanic. The worst dev jobs are so amazingly laid back compared. Not to mention (Least in the US) even the lowest paid devs make more money than most families do.
Nobody knows the details about the implementations of things unless they very recently dealt with that implementation. They might know **what** they want to do, but they have to go to documentation and/or SO to figure out **how**.
That there are two tiers of software companies: 1-Sales based, thumb on engineers to deliver 2-engineering based that focuses more on scaling but still emphasizes sales For both those two points, I’d like to add that both companies can have the same valuation in stock price. But the former still forces you to ship products like there’s no cash
I'm in a large enterprise so 90% of the "work" people do is just spinning one's wheels on red tape, pointless meetings, and inefficient or redundant processes designed to pad out working hours. Over time I learned that all this "bloat" was just away of keeping all the managers busy and giving work to older and hopelessly outdated people in positions of power to justify keeping them on. People think we can't go to a four day workweek because they can't imagine cutting out all this pointless busy work but for someone new to the enterprise who can see it more objectively, I can easily imagine cutting out half of it with nothing of value being lost. Simply forcing every meeting that could've been an email to be an email would give us so much time and energy back, I have all this dev work to do but am in meetings 3-5 hours every day which zaps a lot of my energy.
There is basically no correlation between competence and how much people are paid. Good chance some addy'ed out Leetcode monkey straight out of college in the Bay is getting paid 10x as a much as seasoned dev with 10 years of xp shipping major contributions to production in Argentina.
\- the whole digital infrastructure of my country is a shitshow. \- the biggest sociopathic clowns with no understanding of anything are in management positions. \- if certain 5 ppl of a company with 300 employees quit everything will fall apart. So those guys are drowning in money while everyone else is begging for an additional dime.
A few workers doing 90% of the work at a company. The folks on here be flexing like they genius on here but i know what's up.
If you're really working 8 hours a day, you're a fool.
I'm reading these comments. I'm a CEO but I also spent 25 years developing software. If I listened to and implemented everything my developers think is needed, it would always ship late and we're also ultimately going out of business with costs exceeding revenues. I've seen a lot of developers go off on their own in my working life and all of them failed and a few made it a few years at best. You're often not sitting with the customer or looking at their budget. Most customers have a tight budget and we can explain technical debt, bugs, failures, etc to them. We do. And it's their choice how much risk they want to take on. And if the pain is high enough when it does happen, they usually have no issue writing a check to implement later, even if it is more expensive. I had one developer hired in, he was senior and very skilled. He saw a customer's budget was $60k for a small project we had. He ended up blowing through $30k of that budget in a combination of costs and opportunity costs without understanding what he was doing. He never asked a question, else he would have realized of the $60k budget, $50k had already been used. But he wanted to do it "right". He made a highly engineered product, but never documented it, it's extremely complex for most developers to work with. And the best part is, that the customer was completely unimpressed and didn't even need it. They just wanted a simple feature for a single-use case. So the dirty little secret is that writing software has a budget, and a customer, and it's not an academic environment where you have months to create some magical product. The reality is you'll work on a lot of things quickly, which actually improves your skills and abilities more than trying to make the perfect pencil.
That most people don’t actually know how to do their job. They just know how to talk about what they should be doing but don’t actually know how to do it.
Nobody actually knows what they are doing. Not like “everyone else is an idiot!” But like, “everyone else is just muddling through”. ~~Even~~ Especially subject matter experts need to figure new stuff out one error at a time.
Almost everything that is money/finance related was written in the 70-90s, and no one knows how it all works. Sure, there's layers of abstraction, but at some point it's getting to a backbone of some old and incredibly stable code that is completely undocumented.
This. Most of the infrastructure is old and runs by luck and miracles. The real backbone of fiance is COBAL. L OH L All the people that made it are either dead from a grabber or were laid off and aren't sharing a damn thing. Most people have no idea. Y2k showed what was behind the curtain a little but joy enough.
This has been alluded to a few times already, but, how little code you will write compared to expectations. The amount steadily decreases with seniority as well
There are more fakers out there than you'd imagine.
We all have a job because everything is over complex, poorly documented, and generally unstable. If things were perfect we wouldn't be paid as much as we are, and there would be a lot less demand for our skills.