What do Experienced Devs NOT talk about?
Posted by jalanb@reddit | ExperiencedDevs | View on Reddit | 370 comments
For the greater good of the less experienced lurkers I guess - the kinda things they might not notice that we're not saying.
Our "dropped it years ago", but their "unknown unkowns" maybe.
I'll go first:
- My code ( / My machine )
- Full test coverage
- Standups
- The smartest in the room
GoonOfAllGoons@reddit
How absolutely useless most tech influencers are, yet people care what they say.
bwainfweeze@reddit
I will say that The Primeagen sounds dumber than he is, but I can’t tell if it’s an affectation, his dyslexia, or undiagnosed ADHD. When he drills down from the hot take there’s almost always decent fundamentals there, and I find myself agreeing with him far more often than I expected to.
He does oversell his latest interests but he also abandons them every few years.
takelongramen@reddit
He‘s literally open with his diagnosed ADHD
mawburn@reddit
I don't pay attention to techfluencers, but I used to watch a lot of programming on Twitch and was around when he FIRST started. Like 5-10 watchers max.
I'm pretty sure that back then he was pretty open about his ADHD. But, you're probably just messed up by his affectation because high energy extroverted developers are probably the rarest thing in the industry.
I have no idea what kind of stuff he talks about now and havne't really paid attention to him for years, but he's crazy smart.
tiplinix@reddit
He's really not the worst example. If anything he has some overall good takes and encourages people to learn their craft whilst not chasing the next hot JS framework or whatnot. I wish we had more people like that in the industry. The Theo guy though, what a joke.
jsnelders@reddit
I've spent the last 30 years cherry picking the influences (starting with old school book authors) for insights, then dumping them and moving on.
As I gain experience I soon realise most (all?) of them are full of s**t, or, they stop doing "real work" to influence so they drift away from the realities of everyday production that most of us have to deal with.
Silicon Valley/FAANG talking heads are the worst because their version of "software engineering" in production is vastly different to what 98% of the rest of us "software developers" experience doing mostly CRUD work.
Existential_Owl@reddit
The ones that actually try to teach newbies aren't so bad.
But overall, yes, I agree.
ALAS_POOR_YORICK_LOL@reddit
I dismiss anyone who mindlessly repeats something an influencer said. I had a manager once that got really pissed by this, because he was full of stuff he heard somewhere but didn't know anything from first principle
andlewis@reddit
Timezones
GaTechThomas@reddit
Store everything in UTC and it becomes a simple task.
dogo_fren@reddit
This is the worst way of doing it. Just store the dates together with the time zone. Sometimes you need to store the location too.
GaTechThomas@reddit
"Worst" eh? Quite the opposite.
When storing with time zone, date calculations to get to another time zone as well as simple date math both have to account for both time zone differences and DST changes on the convert FROM side and on the convert TO side.
Storing in UTC allows for simple date math to remain simple, and time zone differences only have to calculate the TO side. Generally, the only time the convert TO needs to occur is when the date needs to be displayed, not in business logic. Convert TO as late as possible, often even in browser logic.
dogo_fren@reddit
Simple counter example: Adjacent team made the choice of storing opening hours for package pickup/dropoff points in UTC. Guess who had to modify all dates twice a year?
Having to account both timezones for time arithmetic is the whole point, otherwise you lose information.
Also, most tools think that dates/times without zone information in local date so you can get silent errors introduced easily, which are very hard to detect.
GaTechThomas@reddit
Those are design issues. Store opening hours are not points in time - they're settings. And tools that use the times will certainly have to be considered - can't blindly send a tool a time without knowing what it expects, and it definitely shouldn't be reaching directly into the database.
jsnelders@reddit
Agreed to store everything in UTC... until you need to back calculate the local time.
I recommend ALSO storing the local date/time plus timezone/offset *at the time* the record is created to help do away with having to reverse calculate it at a later time.
Also, in property/database field name always, always include it it's "UTC" or "local". Don't make the next new developer guess.
bwainfweeze@reddit
But put the current time in UTC somewhere on the dashboard so when your coworker says the shit hit the fan at 11:15 pm but the system didn’t fall down until 20 minutes ago, you don’t have everyone doing the math wrong and coming up with false positives. False positives are hell on triage.
Any offset math gets weird but I think errors cause by looking at events on the other side of 12:00 tend to get mishandled substantially more often.
GaTechThomas@reddit
If everything is stored in UTC, the logic is simple for showing the time in the browser's set time zone. Store it in server time or data source time, and the logic becomes more complicated. Add on DST changes and it's 🥵.
bwainfweeze@reddit
That doesn't work because your coworker says on slack, "I see the first error at 11:30".
11:30 what?
GaTechThomas@reddit
Yeah, that's a coworker issue that can't be solved with code.
bwainfweeze@reddit
No, that’s a human factors problem which this entire comment thread has been about.
BehindThyCamel@reddit
We had this discussion in my team recently. At least for that specific product, IANA timezones both in transit and at rest are the better option. Doesn't have to be the rule, though.
seanoz_serious@reddit
Until an update spans a daylight savings boundary and you're not sure where it originated from.
GaTechThomas@reddit
I'm that case it can't really be treated as a timestamp. You could assume a time zone, and then still should convert it to UTC before storing. Store the assumed original time zone as well.
No-Economics-8239@reddit
For those who haven't experienced this bit of pain and suffering, I highly recommend Tom Scott's youtube video on the topic to get a primer. Time stamps seem deceptively simple until you drill down into how time keeping is completely arbitrary.
petrol_gas@reddit
How you shouldn’t hate your job but you do anyways.
878_Throwaway____@reddit
It's the sweetest job in the world, flexibility, good pay, low physical stress, always in air conditioning, working from home, work anywhere in the world without BS certification stuff everyone else deals with.
And yet...
It seems like everyone wants to do woodworking/farming instead.... Myself included
slayemin@reddit
I've done farming, it sucks ass. Trust me.
delenoc@reddit
It's craft, is what I've found.
Most programming jobs don't give us a chance to really practice our craft, and at heart that's what we really want to do.
wayoverpaid@reddit
That really explains why I'm more annoyed even as I get more successful.
I used to be someone who made things. I was annoyed at not making strategic decisions about what to build, and dreamed of being Director or higher.
Now I am a CTO. Things happen because I command it. But I no longer feel the digital dirt under my fingers. Where I once wrote an elegant data structure, I now write an email affirming to a stakeholder that we can handle the requirements.
On the bright side I do have the mental bandwidth for hobby programming again?
Material-Smile7398@reddit
I think this is a well trodden path, almost every CTO or ex developer senior level manager that I've spoken to laments their lack of hands on coding.
wayoverpaid@reddit
Today I am writing an annoyed set of messages to our new task tracking app which is apparently making tasks disappear with no explanation, so that's fun.
Thrilling stuff.
TScottFitzgerald@reddit
This is really all a matter of perspective and how big your project is - I make games on the side and I really wish I had a team of developers working for me sometimes. There's only so much a single developer can do. It's actually frustrating how slow one person development can be sometimes.
Material-Smile7398@reddit
Thats the problem, like painters getting told to paint by numbers..
cube_toast@reddit
This right here. We're required to provide "business value" at all times and as fast as possible. There's little time to really think through a design and practice your craft. Though I do have days where I'm like, shit, I really wish I could just grow vegetables for a living or open a flower shop, as devs we really do have it pretty good.
delenoc@reddit
It's too bad that the craft of good code isn't really visible to people who aren't coders.
Like you can tell if some furniture is from IKEA or a carpenter made it with their own hands. So there's still some value in spending more for high quality furniture, or clothes, or what have you.
But the idea of an artisan coder who lives in a shop by the binary trees and harvests fresh bits every day for their code just doesn't work the same way
DormantFlamingoo@reddit
Check out Krazam small data on youtube
XzwordfeudzX@reddit
There is, but not necessarily in consumer software. However I'd argue dwm, plan9 uxn emacs et.c. would constitute as "artisonal" software in some sense but might only be appreciated by other coders (though I've heard of writers and lawyers that use emacs)
michaelsoft__binbows@reddit
It does though. I like being able to go in a cave and come back in two weeks (more like two months, hmm) with visualizations beamed to users' eyeballs in 120fps via glorious shaders. Everyone can see the business value when they feel the sexy software being sexy.
Still hard to ask for time to actually go deep to pull this kind of shit hard. The more of them I can accumulate on my portfolio though, the easier it is to land fun gigs that make an impact.
TScottFitzgerald@reddit
It's visible when it breaks
titosrevenge@reddit
Allow me to be pedantic for a minute. Carpenters don't build furniture. Woodworkers do. Carpenters build houses.
cube_toast@reddit
Agreed. End users just see the resulting functionality, not what went into it. They don't care if clean architecture or vertical slice was used, if cosmosdb or sql server was used, and they don't care so long as it does what they need it to do. I understand it, I really do. But it doesn't mean I have to like it!
rorschach200@reddit
For me 'delivering value' isn't even the problem.
It's the people.
It's the sweetest job in the world, it can be a great product, a great project, a great codebase, great work, and yet all of these people that gather together to enjoy all of it know no better than turn the environment into a self-inflicted toxic hell of their own making.
It's such a shame.
Yamitz@reddit
The legions of tech adjacent folks run it for me - all the scrum masters, project managers, systems analysts, etc, etc - who don’t know tech but learned the right key phrases to make good money in “tech”
TangerineSorry8463@reddit
The lightest 'manager wants to talk to you' moment I've had as a junior was once I told my scrum master that I'll respect his opinion on the state of the codebase when I see him do any contributions to the codebase.
It was out of place, but the air of "but honestly you were right" was in there.
bannerlorrd@reddit
This right here. In my corporation there is a function called Program Managers. Worst kind of people. Their only contribution is that they: 1. Push a button to approve deployments 2. Can and need to find anyone responsible when some shit happens.
Gueas who takes the most sick leaves and vacations? Yeap. You guessed it. They are never there when you need them.
TScottFitzgerald@reddit
That's more on the corporate world in general than software. There's smaller shops that don't really have that, but they also tend to pay less and be less exciting.
darksparkone@reddit
That's... not a trade defining thing. I've been through a bunch of places, and seen some really toxic management, but the peers was always amazing. If it's not the case for you consider moving to a different place.
878_Throwaway____@reddit
I feel like I lack three things: ownership, permanency, and engagement. That's my problem. Everything you do is built on the back of other work. Nothing is really "your work" like craft would be. You can do code well, but, typically, no one notices. So effort or mastery has very little social reward. Then, everything you build is tech dependent. When something is a few years old it's just not it any more. Something like furniture is timeless. Lastly, the problem tech solves is genuinely abstract. There's no problem in front of you that you solve up close. Someone, some imagined person, with a process inefficient task wants a better way to do it. You don't see them suffer, you don't see them change with your solution. You'd be lucky to get a "good job." Hell, you'd be lucky to get a "bad job" for bad work most of the time.
TScottFitzgerald@reddit
I disagree with many points here:
Craftsmen don't do things from scratch, they learned techniques from previous generations. The same way you might use a library made by someone decades ago. Why repeat work? Why write the code again if someone already wrote it? Just for the fleeting moment of self satisfaction?
Furniture isn't forever, it breaks down, trends and tastes change, new techniques and materials get developed all the time. Software, on the other hand, is alive. It's meant to be used actively, not stashed in a storage container somewhere.
And thirdly, while it's true that many software developers are very separated from the results of their work, there's plenty of companies that do push for ownership and try to connect the developers with the end consumer and see how their code affects them.
grain_delay@reddit
Marx described this exact phenomenon for what it’s worth
roger_ducky@reddit
Crafting good code is like creating injection molds.
It’s not how fast you can crank it out by hand, but what you can design to crank out the widgets faster than before.
Many times, I provide value by finding the right libraries and frameworks, or standardizing things so they look similar enough that I can do a code generator that takes people 70% there.
Trying to crank out code faster isn’t scalable.
petrol_gas@reddit
Yes. That’s the point I was making. Software Engineering is a totally different thing from what we do in the industry. And the difference between the two is the impetus for like 80% of posts on this sub.
But we never talk about that.
larsmaehlum@reddit
The ladder:
Junior
Mid-tier
Senior
Lead
Staff
Principal
Goat farmer
jbdroid@reddit
Can’t wait for my goat farming stage
Existential_Owl@reddit
As do we all, friend.
invisibletank@reddit
Fuck that I don't want to farm. I got into this to avoid manual labor. My dad recently retired and his knees and back are screwed up from blue collar work, despite being light blue collar, and he didn't want that for me. Coding is great, even if I don't get the time to write it perfectly, seeing the results never gets old.
Distinct_Goose_3561@reddit
When it’s sunny and nice out I wish I could be outside, doing whatever. Physical labor, low mental stress, no worries about a Teams message that something shit the bed.
When it’s pouring rain, or 95f for a week straight, or 25f for a month- those are the days that remind me how good I have it.
william_fontaine@reddit
Seeing my dad get home from working 12 hours outside in -5F temperatures with 25MPH winds made me never want to be forced to work outside. He was wearing as many layers as he could, and it still took him all weekend to stop feeling cold.
trannus_aran@reddit
As someone coming from agricultural botany who's been dealing with this job hellscape for the past year, any programmer who waxes poetic about doing farming instead should trade me their fuckin job and get some dirt on their boots
_AndyJessop@reddit
I do both. The beauty of this job is you can work from anywhere. We bought an acre in a remote part of France. Lots of gardening, wood working, etc. outside of work time.
The other perk is that you save vast amounts of money (life is very cheap here).
I couldn't imagine doing this job and living in the city.
Pr3fix@reddit
Not a lot of roles hiring for fully remote especially roles that allow relocation outside of the home country
_AndyJessop@reddit
Seems like a minor blip then. I've been remote since 2009 and never had a problem finding work.
THIS_IS_4_KNWLEDGE@reddit
I’d argue it’s quite high physical stress, especially over the long term. Sitting all day in basically the same position wreaks havoc on your body. I’m unlucky enough to have had to start dealing with that when I was 23 (I’m 34 now), but it comes to most of us eventually.
I think the problem is we convince ourselves it’s a sweet gig, because we like or liked being in front of a computer all day, but over time that takes a bigger and bigger toll, so much so that it makes us feel shit a lot about our work. And so the idea of doing manual work - as you suggest - is so much better.
That’s not even adding in how much inflammation there is in the average software engineer from the widely accepted terrible dietary practices. (F**king pizza and beer when people are meant to focus and use their brains. Madness). It’s really no wonder so many of us are stressed, don’t like our jobs, and die on too many hills.
I really think it’s less about the work and more about how the long term work shapes our minds and bodies.
casey-primozic@reddit
Don't forget nursing.
Chevaboogaloo@reddit
I think I’d really enjoy being a librarian
bannerlorrd@reddit
Mom's a librarian aaand yea it gets boring. But she does have quite a vast knowledge and simply sits down and writes/knits/sudoku/whatever when she gets bored. So yea, I also think I would love being a librarian and writing code when I get bored of books
darksparkone@reddit
Good luck with that. As someone who did farming, manual labour, client service and stuff being young, it's not about golden handcuffs for me. Just being at an extremely comfortable and stress free place makes most other options pale.
Legitimate_Plane_613@reddit
It comes down to Autonomy, Mastery, and Purpose and the fact that most of us get very little of any if it.
normalmighty@reddit
I'm glad I did a few years of dairy farming before this so I have an alternate career path to compare to. Otherwise I'm certain I'd have romanticized other career paths and fooled myself into thinking it would all be sunshine and rainbows if I switched to a trade or something.
Also racism was a much bigger issue in the rural sector. Sure some devs out there have subtle racist flags, but I have yet to meet anyone showing the kind of open and unapologetic racism towards any of my workmates that I saw on dairy farms, and my farming brothers and dad have all indicated that it really is as bad as what I saw back then.
william_fontaine@reddit
I learned so many swear words and insults just by playing within earshot of the milk truck driver as a kid. Man did that guy have a mouth on him.
william_fontaine@reddit
I hate it because of the headaches. At least one bad headache a week for almost 20 years now. Sometimes 5 or 6 or 7 days a week during crunchtimes.
I did so much tylenol/ibuprofen/caffeine that it started to mess my stomach up after a few years, so I cut way back on those and just live with the headaches now.
It's bad enough that I started constantly thinking about retirement 6 months into my first full-time job.
AbstractLogic@reddit
The business pays your absurd salary. Your job is to make them enough money they keep paying that absurd salary.
Your code is only appreciated by you. It’s a rare occasion in my 20 years I’ve read someone else’s stuff and gone “well fuck me that’s god damn beautiful.”
TimMensch@reddit
I've worked with a few developers who, when I read their code, I would always at least think it was good, and occasionally brilliant.
On the other side, as a lead to an external team I handed the code over to the newly hired internal lead. In the meeting where I was supposed to answer questions about the code, he raved about how awesome it was for a solid ten minutes. Then the CEO came on the line and he started over and raved for another ten minutes.
So ... I guess it depends on who you work with.
Material-Smile7398@reddit
Thats a good colleague, and well done!
Infiniteh@reddit
I've had that with a few devs as well. And I've the reverse where a couple other devs have complimented me on the readability, modifiability (is that a word?), or debuggability (this isn't a word, but you get it) of my code. Or telling me that they learned something from working on my code. Best feeling I've ever had at work.
IsleOfOne@reddit
Knowing when, how, and with whom to build social capital is a critical skill!
Material-Smile7398@reddit
A non developer read and maintained some c++ that I wrote, telling me he could follow what was going on. That was probably the biggest compliment on my code I've had to date.
tech_tuna@reddit
Some of the worst code I’ve ever read and had to maintain was written by one of the smartest engineers I’ve ever worked with. He wasn’t just smart though, he was one of the handful of actual 10x engineers I’ve known,
But he slapped together this one specific app over a weekend and it was insanely unreadable code.
tl;dr even the best engineers write shit code when the circumstances are challenging.
Existential_Owl@reddit
And in the rare times that someone thinks, "Damn, this code is beautiful," they'll likely attribute it to the language or technology.
It's never, "Wow, {former engineer} wrote good code," it's, "Look at how beautiful Python can be!"
SanityAsymptote@reddit
The "absurd salary" also feels extortionately small when you see how much the business actually make off of your work in comparison to how much of that it's paying you.
Working consulting and seeing your time bill for 4x what they're paying (which can also feel like a lot) makes you always somehow feel like you're still getting ripped off despite continuously making more money at every new job.
yetiflask@reddit
You have no idea what you're talking about, this is the most reddit post I've seen.
AbstractLogic@reddit
Your work doesn’t just pay your salary. It pays every business person and janitor in the building, the shareholders etc. the definition of capitalism is you will never be paid for the entire of your work will never be la
TScottFitzgerald@reddit
Yeah...that's how every business works. That doesn't mean developers aren't severely underpaid for the value they create. I've heard it estimated that an average developer in FAANGs generates about 2 to 5 times of their salary.
merry_go_byebye@reddit
But is that not only possible because of the infrastructure and resources they have available at said job? If they want to make EVEN MORE money, then maybe they should take on some of that risk and operating costs and start their own business.
Particular_Camel_631@reddit
Which is why one of the metrics you can use to evaluate a company is “revenue per employee” and “ebitda per employee”.
SanityAsymptote@reddit
I am aware of the need to pay office support staff (even when there's no office) and hold overhead for other business expenses/downturns, but you're making an awful lot of assumptions here, lol.
I was paid hourly at that job, and every dev billed out for the same, yet some developers made more than others and some made less. Someone leaked an excel spreadsheet with everyone's pay and a bunch of us found out that many people were getting paid significantly more despite having less experience and tenure but being close with the owners. This would have been a huge thing had most of the team (myself included) not been part of a layoff a few weeks later when Trump shut down the government over his border wall tantrum and nullifying our contract with the USDA.
After that, I started my own individual consulting business, and charged the whole billable amount for my time that my previous employer was charging. It was all working great until COVID, when a combination of my wife getting very sick and businesses pulling back led me to having to find another regular "job" again.
So no, you're not always going to be on the exploited end of the equation, sometimes you can actually get the whole bag. My personal success just doesn't seem correlated with Trump being president for whatever (extremely obvious) reason.
MoreRopePlease@reddit
2.5% raise also adds to that feeling of exploitation. Oh and no we can't rehire the guy we laid off to backfill the guy who is retiring because we will only hire non-Americans due to cost. Dude, rehiring this guy will save us a lot of time and training! He will hit the ground running and contribute value right away!
dinosaursrarr@reddit
Get you with your 4x. My firm used to pay me 8% of my charge out rate.
met0xff@reddit
When you're at Google or the big Consulting firms yes but I've seen so many companies where most consultish projects are barely net positive if at all. Mostly because both the ppl at our company and the client underestimate effort. It's always "no prob, we can do this in 3 weeks, costs 20k" and then 5 months in I end up coming to the project and hear it's overdue and costs are over the top and the client also is still unhappy with this and that ;). Meanwhile I assume just all the meetings and slack messages of a dozen people cost more than what the client paid lol.
But even after a long time in the field I am regularly shocked how expensive Software can be if it's not scaled to many customers. Especially in the US where my salary is almost 10x my previous salary in Europe.
beaverusiv@reddit
The best I've ever thought about code is "ok this is pretty readable"
loctastic@reddit
Someone said that about my code and I felt like they gave me the best blessing
bwainfweeze@reddit
Someone did this to me in the middle of standup, but I think it was half meant to shame some other people for their god awful spaghetti.
thodgson@reddit
...and that code is usually "littered" with well thought out comments that nearly make me cry. Bonus points when comments include a link. Double-bonus if the link points to a wiki that includes a feature walkthrough, explanation of "why this was done" or other links, e.g. ADO item, etc..
geeeffwhy@reddit
sometimes i give it a “huh, that’s neat way to do it.”
urbansong@reddit
This is true but you still have to pretend that you appreciate other people's code and that this is a real craft and everything. You still have to get hired.
jenkinsleroi@reddit
It's more like, when everything works well, you don't notice the design, because obviously that's how it should work.
Only when things are badly designed, it becomes notable.
seven_seacat@reddit
That last part makes me think of the classic https://www.stilldrinking.org/programming-sucks
Appropriate_Ladder_1@reddit
Burnout is real. Fuck anyone who says otherwise.
No, you will not miss the birth, first steps, birthday, anniversary, etc to fix a build some asshole fucked up because they did not care. If you're single you are visiting a dying friend. Your answer is this: sorry I'll be out of town, end of story. Practice this in the mirror versus worrying about tabs versus spaces.
When headcount needs cutting, and it will, the boot lickers will stab you in the back. Get ready for it and get out in front of it when you can. Work colleagues are that, colleagues not friends. Do I condone it, no but I don't know their bill paying situations.
Some will not listen to reason. Identify these people quickly and try to ignore the fact they climb the ladder the fastest. Practice blank stares like you were thinking about the color wheel.
Lastly, architecture docs are stupid. There I said it.
Leddite@reddit
My tech stack
gimmeslack12@reddit
^(*Its at least the exception to have a mentor, not the rule)
abibabicabi@reddit
If a company allows it mentorship definitely exists. Especially in the form of mob/pair programming as well as brown bags and demos and pr comments.
That and just being in the vicinity of certain engineers will create an environment where different discussions and techniques are just naturally circulating. Definitely much different than the ideas brought up at the gym.
I have definitely mentored many engineers/interns. Less so now.
gimmeslack12@reddit
You are the 2%.
Rakishamon@reddit
I was mentor to a couple of people, what i noticed people doing wrong is they are guiding them by hand.
You just need to point them and say figure this stuff out and call me when you do, than we look at it and say look you could do this like that, and you can see the spark in theris eye, first the dissappintment like wth why didnt i think of that and than ooo this way is soo cool :D
CardiologistSimple86@reddit
Yes, I never need people to spoonfeed me, they just want to and they feel like it.
darksparkone@reddit
While it's rare to have a dedicated nanny-mentor, a lot of devs are passionate about what they do. Ask around, there is a person happy to sit through a problem and help the best they could.
EchidnaWeird7311@reddit
Yep, I've been a shit mentor to some when I've been asked to help them along, but I've taught a lot of people a lot of stuff independent of whether there's an official relationship between us.
HereOnWeekendsOnly@reddit
Unfortunately true. Most jobs since graduation have been about swimming while drowning with a 50kg anchor. Hell, some more senior people even actively tried to not help or even harm my progress.
I now only mentor people who show initiative and give a fuck - everything else is a lost cause.
Dimencia@reddit
I'm gonna go with what seems to be the opposite of the top comments, but the same vein:
You get paid a ton of money because your expertise is valuable, and you're the only one who really understands the time costs of rushing through decisions and producing sloppy code. You have the sway to take as long as you need to, to make the architecture right and make the code good enough that it won't get in your way in the future. Your managers would be perfectly happy with a quick and dirty solution - your job is to say no, that quick and dirty solution will cost us more time in the future, we'll spend an extra week on it now so we don't pay that price constantly from now on
Historical_Emu_3032@reddit
Yeah I just skipped over the frontend unit testing phase, it was so much extra work for not much gain.
FinestObligations@reddit
As someone who is mainly frontend centric I agree that you need less unit test coverage. But you definitely still need some. Otherwise you’re just wasting time in the long run by not catching regressions.
Historical_Emu_3032@reddit
100% business logic should be unit tested
But once we're measuring pixels in storybook and mocking user journeys and checking for icons with jest it reaches insanity.
My biggest gripe is auto testing user journeys, at max you should only write one e2e works are coded.
But a user will likely never interpret the UI or follow that tested process, only dedicated manual testing and bug tracking service can help with human behavior.
It was all just a scam at getting rid of testing costs by loading it all on to devs.
Infiniteh@reddit
This is the kind of thing I think AI could be genuinely good for.
Use playwright or whatever to check if your UI behaves like it should, "if I click this button does a new pop up appear with this stuff in it?".
And then let AI handle things like 'does the page look 95% like this design image?"
Historical_Emu_3032@reddit
No.
freekayZekey@reddit
devs would benefit from taking more humanities courses. a lot of devs have shit command of their native tongue, and it’s sort of embarrassing
Infiniteh@reddit
English isn't my first language, but I can speak, understand, and write it well enough. I've worked on international teams where several team members did have English as their first language and I'm often appalled by their lack of vocab or the limited ways in which they are able to express themselves.
They're all corpo speak and abbreviations/initialisms, but their language lacks colour and nuance.
freekayZekey@reddit
exactly. i am far more forgiving towards people who learned english as a second language. if you were to ask me to explain things in japanese, it would be pretty elementary, so i’m impressed by people who can do it in english.
i am, however, not as forgiving towards native speakers. a lot of them know their grasp of the language isn’t great, and they simply…stay that way. improve! communicating is the most important part of the job
bwainfweeze@reddit
About half the time I post this I get downvoted, it’s up to the vibe of the thread whether I do.
A thesaurus is an excellent tool for naming things and brain storming on design. The words we pick lead to inferences, and some of those inferences are at odds with the requirements. Better to find a synonym that encompasses the actual design better. Especially compared to using the same word in four places with different constraints and logic. Or during a refactor to prepare introduce different semantics.
Life-Principle-3771@reddit
Fwiw I am on the side of people that absolutely hate this. Always use extremely simple language, even if it requires repetitive language or significantly increasing the word count.
We must always remember the audience that we are writing for. A vast majority of people that I have worked in this industry are non native English speakers. The cultural context and linguistic implications of the English language can often be opaque to these people, even those that speak English at a very high level.
I would also point out that many of us work in large multinationals where your documents/code will regularly be read by people working in foreign offices where people may only have an intermediate level of English. This just makes things harder on them and reduces the velocity of work.
bwainfweeze@reddit
Having four different workflows use the same noun and verb for vastly different requirements is not helping anyone. I’m not saying pick a college reading level word. I’m saying there’s more than one word that describes purchasing something. And if the rules differ between them, such as one being a lease and not a purchase, then don’t use the same word and expect people not to get their wires crossed.
freekayZekey@reddit
honestly shocked this has been upvoted much considering the past as well. then again, this might be different because i wrote “native tongue” instead of “english”. that can ruffle some feathers.
definitely agree with you on the inference part. can’t tell you the number of times i’ve refactored some vague integer variable for time related stuff like “wait”. i’m always wondering if it’s in seconds, milliseconds, hours, donuts?
bwainfweeze@reddit
Every major language has a thesaurus. Doesn't have to be English, the point is more than half of us did better on math than verbal during placement tests and boy does it show.
Naming things is about finding the appropriate word, and there's a big difference between knowing a word when you read it in a sentence and having enough recall for it to pop into your mouth when bidden. And also that gets worse as you get older.
That 'command' you mention leads to people saying 'fuck it' and going with the first word that pops into their head before they lose the point of the function they're about to write. A thesaurus is a lot less work to do the same. Pick a better word and run with it.
Rakishamon@reddit
They dont know hiw to speak, in general, and when i mentioned they should attend some courses thet are like yeah let the company pay me for that, and im like dude its like 100$ per month for 3 months top, and it would benefit you further down the road... Then i stoped doing this, no point people in general have superiority complex and ego bigger than empire state building... Like dude i know my code is shit how can we make it bette, your code is shit lets figure it out...
Oh and one more thing, this is proof of concept we will update it, means if you do not update it this is going to the customer...
Consistent-Art8132@reddit
What kind of course do you recommend—I’d be interested in this!
Rakishamon@reddit
It depends on your field, if your english is lacking, look at some of the local english schools, there is also some sort of comunity where you can talk to native speaker and you can teach others your own native language.
Also you can look into tutorials, reading books or online articles/newsletters, regarding the field you are trying to improve, also where you can get the most of it is joining meetings and discussions with medior/senior devs, and architects, you can also view the wikis that they write about the new feature implementatio, or improvement. They will be okish with going deeper with explaining it to you just you need to figure out when and how much is ok to annoy them :D
Additional_City6635@reddit
And technical writing is a pretty critical skill at many companies
w00fy@reddit
And yet…
freekayZekey@reddit
it’s amazing to see how many people overlook the skill. my university required computer science majors to take a business communication and technical writing course.
i was surprised to learn that was rare. seven years in the field and i still get compliments on my documentation. it would be cool if devs took a small amount of time to work on writing. 🤷🏽♂️
popeyein@reddit
This sounds interesting, can you point to the said courses?
freekayZekey@reddit
i did it during my undergraduate, but i did purchase Genadinik’ “business communication skills: business writing and grammar” on udemy for sale for ≈$13 for refreshers.
if you just want quick and easy improvements, you can buy the “Bedford Handbook” by Hack and Sommers. it should be super cheap. when i bought it, it was ≈ $70. it should be a lot cheaper (considering legal means) used considering that was over twelve years ago (man, i’m old…).
the sections are organized really well and there are plenty of examples. the sections are things such as “Grammatical Sentences” with sub sections like “run-on sentences”. that sub section highlights common mistakes. stuff like that
seven_seacat@reddit
I've just made the connection that I did the same at uni, and yes I get the same kind of compliments. Huh.
syklemil@reddit
We probably could stand to have more trained archivists around too. "How do we organise the documentation" frequently has as bad answers as "how do we write the documentation".
FinestObligations@reddit
Infiniteh@reddit
I'm always the first to see my own PRs and I read them in their entirety before adding any other reviewers. I pick out so much stuff this way.
bingo__bango@reddit
Perhaps. But it pays the bills 🙂
BigJimKen@reddit
People treat me like a fucking lunatic when I say this.
90% of the time it would be cheaper, faster, more performant, and have better customer reactions if we just implemented web-apps like they did 20 years ago, but with a nice service->DAOs->models architecture for the server code instead of the lunatic OOP shit they used to do.
People from strong mental models around the software they use, and for a while the mental model of how a CRUD web-app flowed was deeply ingrained in business. Now the default modality is
lets make it like a desktop app but ✨ worse ✨.FinestObligations@reddit
It’s one of those opinions I keep to myself, because it’s going against the current cargo cult.
I see you. I think you’re right. But people are not ready to hear it.
DougJoe2e@reddit
I review the tests.
vegan_antitheist@reddit
Some in my team review tests. When I started right after school I thought I could become a SEO but I couldn't live knowing what I do is just bad for everyone. I don't know what you have against SPAs. I like them. But not for everything.
FinestObligations@reddit
Don’t get me wrong I do SPAs for a living. But they are way more complex than they appear on the surface and they take skilled engineers to maintain.
jl2352@reddit
SEO is a huge mixed bag and most are dumb. Especially passing agencies and contractors. The majority will tell you to do things like it’s secret magic only they know, often being well known basics from the late 90s. I’ve sat through meetings being told how we should have one H1 element on the page (which we already did), like it’s a great discovery that will revolutionise the business. Leaving thinking they could be replaced by a junior web developer.
The good SEO people get involved in content. How it’s organised, what’s working, how the content on a site is linked in ways that make sense, and how it ties into the product and marketing strategies. They get into how marketing can better utilise the tools to improve that, and what’s missing for them to do more. I’ve seen first hand a decent SEO person almost 100x site traffic in six months, with stats proving the visitors are relevant.
FinestObligations@reddit
I've experienced the same. You need to find the good ones and they're for sure worth their price. The bad ones are next to useless.
thodgson@reddit
Email, Meetings, and Availability.
Yes, you hate checking your email, but work communication requires that I leave a paper trail and send you important information that you read, acknowledge, and potentially reply back to me with a thoughtful answer because in order to do things, we need consensus to make decisions.
Meetings are a scourge, but inevitable. They happen. Get over it. Show up on time, participate and let's get it over with. If you are late, we won't just "get started", we are waiting or will restart while we "bring you up to speed" (I hate that phrase). Your input is required in order to make some decisions so we don't have to have a series of meetings - that would be hell - so either confirm with agreement or engage in discussion where you see problems or areas where improvements can be made.
You are an adult and you are being paid to work. During normal business hours, be somewhat available. Don't put yourself on permanent do-not-disturb, go days not responding to a direct message, or when you are out-of-office not setting the flag/message signifying that you are "out".
bingo__bango@reddit
Meetings are inevitable. However, another critical skill set is figuring out when your presence is truly needed or not. Managing how my time is spent means being ruthless about declining invites that don’t have a clear agenda and goal, or when I pressed, the organizer can make do with async communication.
thodgson@reddit
Agreed that it does go both ways. I would just like to acknowledge that there are times when I need your buy-in, approval, expertise, etc. and you don't or may not realize it. That's why you are invited.
DeterminedQuokka@reddit
A hill worth dying on happens once a year max.
Most of the code you write will not be great code, it will be adequate code
Most of the job is boring or stuff you hate doing
I like juniors more than seniors
No_Jury_8398@reddit
Most of my dev job is not boring to me or stuff I hate
BlueScrote@reddit
This is so accurate. There's a couple of engineers on my team with \~5 YOE or so where every decision is life or death and they fail to realize that by crying wolf every week no on takes their opinion seriously.
DeterminedQuokka@reddit
Exactly. I feel like we always tell people not every hill is worth dying on. But we are never clear that basically no hills are worth dying on.
Existential_Owl@reddit
Eh, there are two hills I will almost always die on: 1) basic security practices and 2) good backup procedures.
At a minimum, anything that you want to construct airtight CYA on is something that, by definition, you may someday actually find yourself at risk of dying on.
Schmittfried@reddit
I’d argue ethics is that mythical hill worth dying on.
BeerInMyButt@reddit
The complicated thing with ethics is that it's never cut and dry, there's always room for debate. One person might say that a particular decision has such-and-such ethical consequences, in a very black and white way, then go off to die on that hill. Another person might agree that the ethical consequences they bring up are correct, but that the effect will be vanishingly small. And then the whole thing that the only business that makes no ethical violations in this system is one that does not exist. So like yeah, a person could be bringing up ethical dilemmas all day, but it's not clear which ones are hills worth dying on.
Saying this as someone who has to keep my tendency for moral absolutism in check. For me, I think the root cause is a search for groundedness in a world of ambiguity. Pretty often I'd find myself in a decision space with a lot of variables, overwhelmed by the choices, and then...magically...a moral insight would occur to me that made the decision so simple, how did I not see it before?
wardrox@reddit
I just don't really want my work to be increasing suffering, in general.
Admittedly nothing makes me suffer more than my own code, but that's a separate issue.
BeerInMyButt@reddit
I honestly don't know how to take a work-related action that does not increase suffering somewhere. I think the notion of a zero-splash entry is misguided. We take up space by existing, and every act of creation is accompanied by destruction.
wardrox@reddit
Very true. I do think there's a utilitarian angle too though, which differentiates based on how the things we produce change in the world. Eg working for a kind homelessness charity compared to working for a nefarious gambling company.
If we assume different things cause different amounts of suffering as an output, which I think is reasonable (at least within a finite scope), then our choice of work is part of it.
anonyuser415@reddit
A childhood friend wound up working for a defense contractor making AI-powered weaponry for the government.
I can't tell you how quickly I lost respect for him when he told me.
Schmittfried@reddit
To be fair that kind of weaponry does save lives so I see where somebody willing to do that is coming from (hopefully, they could also just not care).
But I can’t understand how anyone is fine with implementing dark patterns to coerce people into subscribing to things or outright scamming them. No value is created that way, it’s one of the few things that are objectively despicable.
Schmittfried@reddit
Sure, but you don’t have to defend someone else‘s ethical values, just your own.
BeerInMyButt@reddit
That's true but I'm not sure how it solves the dilemma I laid out
spaceneenja@reddit
This goes both ways. If the engineers are collectively pushing back that hard on decisions maybe you have bigger problems brewing.
Patient_Ganache_1631@reddit
This. Dealing with a diva like this right now. He is not being considered for a lead position despite being quite good at coding.
Inability to compromise or have perspective is a killer.
ChessCommander@reddit
I think the point is that not every part of the system needs to be crafted well. If the architecture is well and good and nobody is trying to change it for the worse, then who cares if submodule 12 isn't written well? Those that do care speaking up means they don't understand priority. Also, I think those devs are just trying to keep their sanity.
jl2352@reddit
The development speed is a huge factor, and many engineers I’ve worked with don’t get how much of a time sink the debates have.
I’ve seen multiple times that when you ’lower’ standards to make decisions quicker, you end up with higher test coverage and a better architecture. Whilst also moving onto the next feature sooner. The time saved is spent doing things that matter.
Engineers also have this notion they only get one chance to do it right. Go quicker, and you can fix up and improve the issues as you go, as it’s always a much quicker ticket.
ForeverYonge@reddit
At too many places, a feature that was hastily thrown together as a demo gets shipped and never gets any time to properly rewrite it for scale and maintainability unless it’s literally on fire and customers are lighting up the phones. Engineers who care about getting it done right the first time have those scars.
FrankRicard2@reddit
Nothing is as permanent as a temporary hack
budding_gardener_1@reddit
This.
A junior throws shit together and calls it good. There are issues with the implementation but your concerns are handwaved away in a "it works so STFU and stop causing trouble" kind of way.
More and more things are built to depend on the shitty architecture until it reaches a point that a refactor is needed because another feature doesn't work without it. Except now a 2 line change that could've been made 3 months ago now requires several modules be rewritten entirely.
BeerInMyButt@reddit
It's so interesting to me how this is industry specific, and in other industries, the notion of having only one chance is correct.
I have a background in structural engineering. And that was tricky, because the technical debt gets baked into the building and you don't have a way to refactor it. Encourages a totally different way of thinking. fwiw that difference in perspective largely explains why I switched industries - software aligns with the tinkering archetype, structures align with the archetype of "let's make this decision and never revisit it again and if someone tries to bring it up again let's dig our heels in even more because what am I gonna do, start staying up at night wondering if I was fucking up on all those designs for buildings that are now occupied????"
duttish@reddit
I find myself recommending this article at least once a quarter. https://martinfowler.com/bliki/SacrificialArchitecture.html Don't aim for perfect, aim for good enough because each iteration is just the next step of learning what we really should be doing.
Also, good code doesn't have any value in itself. As long as it solves the problem well enough and doesn't cost too much to run or maintain it's probably good enough that we can move onto the next problem.
Theoretical-idealist@reddit
Yeah our sanity matters!!! Casually talking about driving us to madness, what are you? Who are you working for? Better not be enabling the owner class to exploit your fellow man…
Abject_Parsley_4525@reddit
My boss is the guy dying on every fucking hill man. Gosh if the markets were better I would move on I think. You would think that he is new but he has about 20 YOE. Some people are just like that.
AlexFromOmaha@reddit
Here's hoping my current team doesn't know my Reddit.
I got moved onto a team with a pair of tech leads, one for each side of the transaction we're responsible for. The one for the later half is humble, involved, and hands on. The one for the early half is very smart, organized...and barely knows the language the product is written in. His contributions aren't getting into the weeds with the team. They're an endless litany of ideas and ideals. They're good in isolation, but man, you can tell he's insecure in the role and overcompensating by trying to have ideas and input everywhere.
tommyk1210@reddit
100% - there’s at least one person in my org I can think of who is like this. At first it was refreshing that they were so passionate about their work. Now it’s just tiring. I don’t want a fight about every meaningless thing.
Fair_Local_588@reddit
In a more abstract sense they’re burning social capital. These people are exhausting to work with unless they’re generating obscene amounts of capital with the same people in other ways.
777777thats7sevens@reddit
There's a senior engineer on one of our teams who has a ton of experience and is highly respected for his opinions and knowledge, but who will never move into a true leadership position because of exactly this. If he had his way, every single engineering decision would be debated ad nauseam in an open forum until every member of the organization has reached consensus and every detail has been hammered out. And like, that sounds great but it gets to be impractical when your engineering org has 150 people and nothing gets done because everything is constantly screeching to a halt so we can collectively bike shed decisions instead of delivering code.
I respect him a lot and value having him in our organization, but only as long as he is in an advisory capacity where you can hear him out and then decide for yourself if his concerns merit more deliberation or if it's better to move on and re-address later if it becomes a problem. He's right often enough that I will almost always run big decisions by him -- very often he points out something that I hadn't considered -- but he will also drag meetings into eternity debating an issue that, if it proved to be a problem, could be fixed in less time than we spent debating it.
funbike@reddit
I saw a meme about this. Juniors are meek, and seniors are careful. Some middle developers are filled with enthusiastic zealotry.
I went through this progression.
malthuswaswrong@reddit
The secret to my success is knowing how to make anything interesting to myself. There are always hidden secret levels of interesting to every task.
rcls0053@reddit
After ten years I simply think every task is a boring ass chore I need to do. You spend more time around the code, communicating stuff, attending meetings, waiting or reviewing PRs, trying to sync up with other teams, than in the code where I want to be. I've almost ended up working in a way where I spend half the sprint just procrastinating and I still get everything done in the time I have left, very easily.
damagednoob@reddit
Sounds like you need to join a platform team and/or become a 'platform engineer'. Much more technically satisfying, if you are that way inclined.
Distinct_Goose_3561@reddit
For the hill worth dying on- it never is. If I think something will be a shit choice or come back on my team, I just escalate up with the options (keep as is, change X, whatever) and get sign off.
It’s really just ‘disagree and commit’ and for a junior is the path to much better mental health.
tommyk1210@reddit
So so many people need to embrace disagree and commit. Outside of obviously terrible choices, there is little that can’t be fixed later. Obviously we want to try make the best software we can, but there’s an almost 0% chance we completely agree on how to get there.
Be happy to disagree and commit.
seven_seacat@reddit
I hate the phrase 'disagree and commit'. In my experience, it's always leadership using it to ensure things get done their way, no matter what.
Distinct_Goose_3561@reddit
At the end of the day that’s the job of people in leadership. They may be wrong, not very good at the job, or any number of negative things but they are still the ultimate decision makers.
If you are in an IC role and have no interest in management- this is just something you need to accept. It’s true not just in software but really any business.
If you are in the management track or want to be then you need to learn to get along with those in higher leadership positions even if you disagree or you need to leave the company and get a role elsewhere. The grass might be greener- there really are great managers and upper leadership out there- but they may still make that shit choice from your point of view because they are responding to pressures you aren’t aware of.
Dry-Aioli-6138@reddit
this is a worldview so limited it doesn't realize it is not the only one. Read Accelerate, the state of DevOps report. You will see that in elite performing orgs it is not the management making decisions. Technical decisions are made by people actually close to the work.
damagednoob@reddit
Technical decisions are not the only type of decisions that engineers disagree with.
tommyk1210@reddit
What’s the alternative?
Disagreeing and committing is about putting your own opinion aside for the benefit of moving forward. Without it you just end up with an argument until someone forces a decision. When it’s forced it’s always done by someone with the most seniority.
If your leadership isn’t also disagreeing and committing then that’s a leadership problem. I disagree and commit often.
seven_seacat@reddit
I’m not saying the concept itself is bad, but I’ve never seen it applied well.
C0demunkee@reddit
totally agree.
the UCMJ (military law) says you must obey a lawful order when given, but gives you a route to complain after the fact. same vibe.
Theoretical-idealist@reddit
How do you phrase that?
tommyk1210@reddit
“Alright X, I don’t think this is the best way forward for the reasons we just discussed, but I’m happy to disagree and commit so we can move this forward.”
Theoretical-idealist@reddit
And it’s not the same as “fuck you, no”??
tommyk1210@reddit
It’s completely different.
“Fuck you, no” is saying “I don’t care what you say, we are doing it my way”
“Disagree and commit” is saying “I disagree with your choice, but I’m going to go along with it to keep things moving”
ProfessorGriswald@reddit
Not in the slightest. You’re making your disagreement and opinions known and clear, but prioritising being able to make progress. As said above, there’s very little that can’t be handled later on. Progress (and momentum) are more fragile than most realise, and as a senior technical leader you want to be known as someone who respects and prioritises that, rather than as someone who jeopardises it for the sake of their own opinions.
Fun-Patience-913@reddit
Third line, third line, third line. To all the juniors here please read and understand the third line.
mrfoozywooj@reddit
adequate code is better than amazing super efficient code in my opinion, I want something that the whole team can understand not just the top end.
stalefish3169@reddit
Mmmmm hmmmmm. Grug know complexity baaaad.
Dry-Aioli-6138@reddit
Grug know 80-20 rule.
Dry-Aioli-6138@reddit
Grug know 80-20 rule.
levelworm@reddit
I think it's more like once per lifetime, or a few times maximized.
So far I haven't seen that hill yet.
tcpukl@reddit
It's a shame you hate most of your job. I glad i couldn't say the same.
jellybon@reddit
This 100%. Most of my seniors are the type of guys who joined the company in 90's and have stopped learning new things ever since.
schmidtssss@reddit
Mostly agree - I like seniors who take something and build it and come back with relevant questions.
tonnynerd@reddit
I think you're overestimating how much my life is worth, and underestimating how much I like to fight on hills XD
FatHat@reddit
How we actually work. I think a lot of us think our workflows are so commonplace we dont share them, so the only people that do seem to share their process are selling something (usually not good, some *DD or vapid SOLID crap)
TScottFitzgerald@reddit
The fact that most people on this subreddit probably aren't as experienced as they think they are.
Existential_Owl@reddit
I'm most certainly not as experienced as I think I am.
And yet, I'm still the principle engineer and highest authority at my company.
The real hot take is that most experienced engineers are just as clueless as the newbies most of the time. The only difference is that we've just developed a better mental algorithm for pushing ourselves moving forward anyway, regardless of how lost we are.
AnthonyMJohnson@reddit
The highly upvoted “no one ever looks at architecture diagrams after they’re first drawn” comment in this very same thread is giving me this impression.
wraith_majestic@reddit
Dunno, ive worked a bunch of places that 100% accurate. The arch diagrams were just fire and forget (same with ERM diagrams) to check the box on required documentation. Was absurdly uncommon to even update them as the project progressed. Because the review which they were created for was never repeated.
Maybe ive just spent my life working at terrible places? Entirely possible.
GaTechThomas@reddit
Yes!
Torch99999@reddit
Amen! Preach it brother!
damagednoob@reddit
There's never enough documentation. Accept it and learn to be productive without it.
Urtehnoes@reddit
Full test coverage issue not as important as everyone says it is. :/ lol
Slow-Entertainment20@reddit
I ask devs to write tests so that they are forced tot think through how they are doing something, not necessarily because it prevents bugs.
Urtehnoes@reddit
Yea, my company literally does not write unit tests ( decades ago the cto had something against it, now it's just company culture), so oddly enough our process instead is the devs and testing teams work very, very closely together detailing how things work, and each ticket gets a detailed test suite in excel. With all rules outlined.
With every change the tests run through the scenarios again.
It works really well. Although a bit odd admittedly whenever we hire a new dev. But we've been in the business for decades and are one of the bests (non tech, niche industry). We just call them human unit tests.
XenonBG@reddit
It works really well probably because your company doesn't have serious competition in the niche, so the incredible loss of velocity these human unit tests cause matters little.
Urtehnoes@reddit
No we've beaten out all the competition lmao.
And we have incredibly fast velocity.
Many folks online are just too wired into how the big 5 operate. There's lots of different ways to excel in this industry :)
bwainfweeze@reddit
If you can’t deploy a change quickly you can’t roll back a change quickly.
And this can make feature toggles be at cross proposes with CI. 9 times out of 10 you can just disable the toggle to turn off the broken code, but feature toggles can be implemented incorrectly and rollback does not work. Now it’s revealed as the process crutch it has always been, which you have taken for a walking stick.
hooahest@reddit
Yeah fuck that shit, I would not work in a place without unit tests. ESPECIALLY if it's on purpose, led from the higher ups.
This is the most insane thing that I've heard in a long ass time
bwainfweeze@reddit
You will get people who make the exact same errors in their tests that they were making two years ago.
Slow-Entertainment20@reddit
Not sure I understand the comment? So don’t do unit tests at all? Ideally you would point it out during review.
bwainfweeze@reddit
Get people to write better tests before you ask them to write more tests. It’s better to see the gaps of code coverage as work left to do instead of having a bunch of bad tests that obscure how much of the code really isn’t covered.
Typically I see management want to move to high coverage at least 9-14 months before it’s prudent to do so.
XenonBG@reddit
When writing unit tests you are the first reader and user of your own code (unless you're doing TDD). I find that very valuable you get a very good idea if the code reads well and makes sense.
vinny_twoshoes@reddit
god, when i was first starting out i literally ended an interview process because the company's codebase didn't have complete coverage. i picked up the idea that full coverage was extremely important in code school, and i thought it was an indicator of the quality of the company. i was a little shit
DistributionOk6412@reddit
i'm one of those that aims for 90% coverage. good tests with high coverage bring so, so much value. there is only one metric that determines how many bugs your code has, and that is the number of lines of code
777777thats7sevens@reddit
IMO good tests are way way way more important than super high test coverage. But writing good tests 1) is a skill most devs don't have, 2) requires structuring your code in a way that makes it easy to test, another skill most devs don't have, and 3) requires sitting down and thinking for awhile about what the intent of your code is, which doesn't necessarily mesh well with churning out tickets.
GaTechThomas@reddit
Line coverage or coverage of acceptance criteria?
FinestObligations@reddit
I would go further and say that in most cases full test coverage should not be the goal but rather something like 60-70%.
derjanni@reddit
Brutal truth: A lot of self proclaimed experienced devs aren’t that experienced.
Blue-Dragonfly-6374@reddit
The fight club. The do NOT talk about the fight club.
Most_Double_3559@reddit
Oh, interesting question... A baseline entry: "which programming language is best?"
A decent number of people can't start a hobby without getting "the best gear", I think of this question as the software equivalent. Meanwhile, the experienced devs just know its Kotlin and don't have to ask ;)
666codegoth@reddit
It is definitely Kotlin 👌
fojam@reddit
Not sure if bait but I gotta stand up for C# here. .NET definitely has its problems with weird competing versions, but the language and framework have both come a long way and are really just convenient as hell to use
syklemil@reddit
I think the experienced dev take is more that "my favourite language isn't the same as your favourite language, and that's OK"; alternately replace "language" with "tool".
There are some caveats here, i.e. I expect the favourite language to not be a Turing tarpit and the favourite tool to usually not be nothing.
FinestObligations@reddit
But that’s just the thing; most languages languages have come a long way at this point. Weak languages like PHP, JS etc are so much better to work with than they were 10-15 years ago.
fojam@reddit
Nah fuck both of those languages lol (they're fine)
UntestedMethod@reddit
Complaining too much about things without considering the business history and reasons why something the way it is, especially on a codebase that's been around longer than their career.
Conscious_Support176@reddit
Yes there’s always a reason. Sometimes, lack of technical knowledge. Sometimes, the techniques used have been superseded, it just hasn’t been updated. Sometimes, it’s done a particular way for nobody knows what reason, but when you fix it, it will turn out to be because of business assumptions nobody thought to document.
nasanu@reddit
OtaK_@reddit
To modulate your third point, while that's true, it's unsustainable (bus factor). But something that is often overlooked is that there are critical sizes for productivity where more people is less speed (mythical man month etc). There's an inflection point where a certain amount of people equals more work being done and beyond it it's just processes and processes.
nasanu@reddit
Bus factor is determined by complexity, not number of devs. And I was in a team of 14 FE devs, we started as three and did less with each addition. Complexity shot up each time and the difficulty of coding without destroying what others were doing was insane. Maybe you are only experienced in BE, but in FE it doesn't work.
OtaK_@reddit
I think you're mistaking the concept of bus factor. I'm literally talking about "what if you get hit by a bus?". If you're a solo dev the project is over. It has literally nothing to do with complexity.
It's also true for front-end matters. And yes, I'm experienced in both (and more, because I do software, not "one area of software").
nasanu@reddit
No, because I would be using the most simple code literally any FE dev could take it over. The bus factor comes into play when you cannot replace devs, as most FEs cannot be replaced because zero other devs know they exact stack.
There is no bus factor when a dev can easily be replaced. If devs need training before being productive then the bus factor is high.
OtaK_@reddit
Do we agree that it’s only true for entry-level jobs/gigs? Maybe I get what you mean on complexity but I disagree fundamentally: if all you do is junior-level complexity where no bus factor can ever exist, are you really a senior?
nasanu@reddit
Well no. If you are writing code a junior could not understand then you aren't ready to be called senior.
For example I just took a translation function and rewrote it. It was complicated and used react context, thus could not be used for half the app which was outside of react. I made it far more simple using only standard JS but also included an object proxy. I commented that this allows an object to have getters and setters, this in turn allows us to see if a key exists in the translation file and return the key if it doesn't, and also log an error. A junior might not know proxies exist and I would not expect them to implement one in a translation function. But it's only a few lines and they should instantly understand what it does just by reading it once. There is no bus factor there and this applies to basically everything.
Another thing was a select option list that basically handles an infinite number of entries while remaining performant. The ideas behind it may be complicated but all code is simple. I have asked several colleagues how they would do this, even a few "seniors" and they all gave unacceptable answers. But you can do it in super basic code, each little bit building like lego into something greater. There is no fit junior in the world that can't understand that I am measuring the outer divs height, then finding out how how many entries fit inside that box, calculating how many entries are left in the list to add padding to fake a scrollbar etc. Complicated ideas sure, but again all code is junior level.
You are senior because of your ideas, but if you execution isn't simple then you are just a bad coder.
OtaK_@reddit
There's way more to writing code than the simple technical aspect of making the code simple. Code is meant to translate and/or absorb a domain-related problem space. So that's what I meant by maybe I understand what you said about bus factor only existing when complexity also exists.
I guess we just are used to work in different industries. For me the bus factor is unavoidable, probably because of the ambient high level of complexity. E2EE messaging protocols aren't easy to grasp, no matter how many abstractions you slap on top of them. Systems engineering is hard, even with the highest-level abstractions you can present, etc.
FinestObligations@reddit
Code Reviews are essential for compliance and having less skilled engineers blow their legs off.
CardiologistSimple86@reddit
No one says you have to blow your legs off if your manager backs up whatever you do as the word of God.
yxhuvud@reddit
I find the necessity of 1 vary a lot. There are people out there that can be fantastic developers and usually wildly productive, but that constantly either solve the wrong problem or solve it is a much more complicated way than it should be solved. Those people really need the review step.
And then there are people out there that hardly needs any reviews at all and solve the right problem without any fluff.
GaTechThomas@reddit
And code reviews are also about the reviewer learning what was done.
janyk@reddit
Oh god, thank you! I've been calling out points 1 and 3 for years and everyone thought I was batshit insane or completely full of shit! And to hear it from someone with 30 YoE is really vindicating!
My first job as a software engineer was as a student (later full time employee after graduating, I was there for a while) where I worked on a team of 3 devs writing custom software for an org where we handled 8 or so software projects that handled multiple business functions - HR, accounting, finance, quality management, identity management, administration, and some custom apps that would identify the org - all by ourselves. Each of us specialized on 2 projects but occasionally rotated onto other projects just to keep the bus factor high. We never did code reviews, just pushed work to the main branch after testing, and the quality of our work was deemed impressive by our users. Our team lead who mentored us was a highly ambitious developer who stayed abreast of trends, was a lead on some popular open source projects, and he later moved onto FAANG, so it's not like we were a bunch of hackjob amateurs that didn't know what we were doing.
When I left that job and moved into private industry, I noticed that companies had teams of dozens of devs doing the work that my previous team was doing with 3 people, and doing it with visibly worse code quality despite their code reviews. The first time I sat in a code review I realized how dysfunctional and meaningless the whole charade was - it was just "even though it works, that's not how I would have done it" over and over and over again. Then it led to work being held up in code reviews for superficial changes, the team lead using the code review process to experiment with his own code suggestions in a back-seat coding kind of way, my concerns about unhelpful reviews being dismissed by my boss, and then my boss assuming that taking multiple reviews to finish a task means my code doesn't work even though I told him what was happening and then firing me for it. Yeah, it was nasty and I'm a bit salty about it.
BlueDo@reddit
I think the quality of people is a huge factor in this. If employees are leaving inconsequential feedback, they're probably not skilled enough to see the bigger picture, and wouldn't have cut it in your first job.
ALAS_POOR_YORICK_LOL@reddit
I talk about 1 all the time and sometimes people disagree but it always leads to healthy discussion. Generally I find people are open to doing review better.
3 is true but there are usually other reasons that 1 man teams aren't acceptable.
I think it helps in reviews to always communicate the severity of your comments. A lot of my comments express a preference, but if you make a case (almost any case) I can be swayed. Other comments are more like "hell no you aren't adding that broken crap to my project," and I always try to make it clear which is which
nasanu@reddit
Yeah that has pretty much been my experience in many places. Even earlier this year I had a PR marked as "needs work" because I commented out a function (that I thought we might need later, comments are not even shipped) instead of deleting it.
I can even refer people to Google's engineering guidelines where they spell out to quickly pass PRs with "issues" like this, but still people insist and stopping PRs for no good reason.
My best one was about 2 years ago when a dev blocked my PR because I used a HTML button and not a react component that returned a HTML button. So not only did it work perfectly, but he insisted that I add bloat because its best practice apparently. You MUST type
DeterminedQuokka@reddit
Firing someone raising velocity is a thing we should talk about more
gnackthrackle@reddit
What it’s like to move into an EM role and just well and truly fail at it, like truly truly fail at it. And then failing upward into another EM role and maybe another one after that, until you finally realize you have somehow become an actual failure of a human being.
And then moving back to IC and just kinda picking back up where you left off as if nothing ever happened, and ultimately remembering why you got into the industry in the first place. And then being astounded that it took you so long to realize what a terrible EM you were and wondering how you could have spent so long blaming your problems on your circumstances and not realizing that all along the problem was you. And then wanting to go back and apologize to all the people you wronged, but realizing it would just be awkward and wouldn’t do anybody any good.
And then just kinda shaking it off and sitting down to crank out some code, because that is what you’re good at, that is what you were always good at. And realizing that by doing the thing you’re good at and not the thing you’re bad at, you’re actually making the people around you better off and making one teeny tiny corner of the world a better place.
Jaded-Asparagus-2260@reddit
Don't be so hard on yourself. Having the realization that you're not a good EM, and then even acting on it, makes you a better EM than 70% of all the managers I ever had.
gnackthrackle@reddit
Thank you, I appreciate the kind words. We can never change the past, but we can take responsibility for ourselves and be better people in the present.
CardiologistSimple86@reddit
Do you feel responsible in any way for other people’s careers and how they ended up after they worked with you?
gnackthrackle@reddit
At least for all the ones I know about, they all seem to have done fine? I didn’t ruin lives or careers or anything. I was just an idiot.
CardiologistSimple86@reddit
How do you know?
gnackthrackle@reddit
Mostly looking people up on LinkedIn, but also my memories of where they were at or what they were doing when I left. Maybe I was being too hard on myself in my original comment? Not entirely sure what you’re picturing in your mind of who I was or what I did.
I mean I was absolutely an idiot and I’m sure there were a few people who hated working for me. But some people liked working for me. If I were to guess, I think people mostly made fun of me behind my back. Most of the harm I did was to myself.
But to answer your question, no, I can’t be 100% certain that I didn’t have lasting negative effects on people because how can you know? The best thing I can do is just learn from my mistakes and never ever ever under any circumstances accept another management position , even though I’m kinda always being offered chances to step back into that role.
It can be difficult to turn away well-paying work, especially when I’m unemployed or looking for work, but experience has taught me it’s just not worth it. There’s no amount of money that can convince me to sacrifice my sense of self-worth.
I’m sorry if you had to deal with bad managers in the past. I hope you’re doing okay.
CardiologistSimple86@reddit
You probably are. I guess if you know people made fun of you behind your back, it's different than if you intentionally acted against someone or tried to fire them for example.
lurking_physicist@reddit
I'm trying so hard to skip that step in my career (because I already know the conclusion that I would be horrible as a manager), but the pressures and incentives all push me toward that direction, and others resent/punish me for resisting.
gnackthrackle@reddit
Just don’t do it. Management is not a promotion, it’s a different job entirely. And just because you are a good worker bee is no indication you’ll be a good manager. Honestly I think management should be (significantly) lower-paid than being an IC, just to discourage people from doing it.
I feel like nowadays people say “management is not a promotion” but I don’t know how many people believe it. Something about the ability to hire and fire and being a “boss” makes the job seem prestigious. When actually, having power over other people is the worst part of the job because it introduces a really painful power dynamic that makes it hard to relate to your direct reports.
I feel like companies have gotten a little better about this over the years by introducing a “technical track” in addition to a “management track,” but even this has limited success because a given company can only really support so many staff engineers, principals, etc.
The real answer is to discard the notion of “forward career progression” entirely. Be happy with being a worker bee. Accept that titles are meaningless. Do a good job and help your teammates, but don’t let the company trick you into doing extra work for free. Look for fulfillment in your life outside of work. Don’t be obsessed with someone else’s idea of “success.” Wish I had learned this earlier in life. Really they should teach it in schools.
IsleOfOne@reddit
Code is only half the job, and it's the easy half. People are the hard part.
jab-programming@reddit
And burnout
IDatedSuccubi@reddit
One man's anti-pattern is another man's best practice
matthra@reddit
Best Practice is more often a marketing term than than a useful heuristic.
Blecki@reddit
And yet dev ops insists on a TAD for everything. They're all just bullshit.
GaTechThomas@reddit
You should have to work in a mature system that didn't include the efforts that go with architecture diagrams. It will change your mind about their value.
Blecki@reddit
I have.
And I'd agree if, like, they actually looked at them.
DeterminedQuokka@reddit
The point of an architecture diagram is to frame having a think not to ever reference it again.
angrathias@reddit
I find cloud architecture without a diagram to be an absolute pain in the ass to otherwise mentally visualize. Maybe I’m doing something wrong, I dunno
account22222221@reddit
Exactly this.
The architecture diagram is to show to your higher ups — see this is what I spent two days taking my really long showers drawing on the shower door over and over to figure out. It’s to prove you actually worked something out.
joshcam@reddit
It’s like writing a prompt for an EILI5 LLM, where at some point many paragraphs in you come to the realization that the architecture finally, actually makes sense and this just might work.
bilbo_was_right@reddit
Perfect is the enemy of good. Debating architecture for weeks when it doesn’t really make any difference is worse than picking one and being done with it. (The ‘not making any difference’ is important to know though)
coffee_sailor@reddit
I really appreciate the concept of 1-way vs 2-way door decisions. Choosing an architecture, implementing something, learning pitfalls, then picking another architecture later is often quicker than debating all week. Time boxed POCs are also super helpful.
william_fontaine@reddit
This is why I don't care about style guides or linting. It doesn't make any difference and people spend way too much time arguing about them and writing them.
bilbo_was_right@reddit
That… is not the same thing. Just use an auto formatter, there is no reason you should be varying any of that stuff when a format can standardize it for you.
william_fontaine@reddit
That's fine. Or we can not use one, and people can use separate styles.
Most of the projects I've been on in 20 years have worked like that and I'm perfectly fine with it. Other projects have had someone that wanted to use one, and I'm OK with that too.
I just don't care one way or the other. Developers should be able to read code regardless of minor format differences.
bilbo_was_right@reddit
Strongly disagree. A senior devs role is partially making sure to set up a system that is maintainable to contribute for everyone on the team, including for example junior engineers.
Code style should never be something you have to comment on in a PR, and an auto formatter avoids this issue. And there are most definitely some coding styles I’ve seen from junior devs that are worth commenting on if they were to not be auto formatted. It’s similar to variable naming, variable names don’t change what your code does but it can definitely influence comprehensibility if done too poorly.
No-Brush-7914@reddit
It depends
I’ve worked with teams where it just wasn’t necessary, everyone was smart enough to follow the existing style of the code
bilbo_was_right@reddit
When you get more experienced, you can be looser with all rules, not just this one. Rules aren’t necessarily “what absolutely needs to be done 100% of the time”, they’re things that will generally be helpful as a sensible default regardless of skill level.
For example, do experienced devs need to fix every single security vulnerability that GitHub tells you are in your dependencies? Well no sometimes it’ll tell you about a vuln for a tool that isn’t used or is a helper script that is low priority and not vulnerable to a ddos attack or something. But that doesn’t mean that it’s not a good rule to have to fix security vulnerabilities in your dependencies. You can just be more selective with your rules because you know the impact. If you know you are always going to hand-write readable code, yes using an auto formatter could potentially do literally nothing. But the point is to use a set of sensible defaults that you don’t have to put any thought into.
The overarching rule is: think about what is beneficial for your business. If you’re thinking about code styling, you’re wasting company money. And not using a code formatter I would argue wastes company money on average vastly more frequently than it is unnecessary. You’re making a straw man argument that is an exception to the rule.
No-Brush-7914@reddit
I totally agree, as long as the style is “reasonable” and not something crazy I don’t give a shit
bwainfweeze@reddit
And the problem is often that the person making the argument is defending the mediocre, not the good, and claiming the good is an attempt at perfectionism, instead of just not being shitty.
Maximum_Peak_2242@reddit
The ‘not making any difference’ is important to know though
This is something that, ideally, should come with experience and maturity, but doesn’t always. There is a definite evolution from “This is the way I would do it. I don’t see any problems with it, so I don’t understand why we would do it any other way” to “This isn’t the way I would have done it. But having thought about it, it is as good as / better than my approach, so I am happy to go with it”. But devs who can really do the latter are rare.
tommyk1210@reddit
Perfect isn’t just the enemy of good, it’s the enemy of your customers.
Sure, you could take 6 months writing perfect features. Or you could build what the user needs in a month and give them 5 months of usage.
People often forget whilst crafting that perfect feature your user has nothing.
It’s exactly the reason why during an incident the top priority is containment. The long term fix comes later. If more people focused on user value rather than ego many businesses would be in a much better place.
TangerineSorry8463@reddit
>Sure, you could take 6 months writing perfect features. Or you could build what the user needs in a month and give them 5 months of usage.
As someone who is in a somewhat-Cloud somewhat-DevOps somewhat-DevEx position, that's exactly what I say. I'd rather try to make a PoC-level improvement for other devs and get them invested in early in the feedback process, than try to invent something they will feel like they had 0 buy-in into.
RighteousSelfBurner@reddit
Also 100% of the time the perfect feature is not actually perfect. Once it hits the user base suddenly it turns out that what developers think and how the user actually uses it isn't the same.
And then you have to work on the feature a good chunk either way to actually make it great. Way simpler to just get out something decent and polish based on feedback.
wraith_majestic@reddit
Yeah Patton nailed that:
“A good plan, violently executed today, is better than a perfect plan next week.”
PopularElevator2@reddit
There's not enough good tech people in leadership positions in companies. Almost all companies i worked had a vp of hr with a hr background/masters, a vp of accounting with masters/background in accounting, while the vp of tech oriented had a accounting or business degrees.
Subjects that are not talked about enough are debugging, telemetry (this has changed recently), and error handling. Yea, you have books or courses with a chapter dedicated to it, but compare that with testing. Testing has tons of courses and books, which it's the only focus.
GaTechThomas@reddit
Do it right. Take an extra 20% of time now and your future self will thank you. Don't ask for approval, just do it. Nobody will know that you could have cut corners like most other "programmers". But you will be able to show later that you're code doesn't require as much maintenance.
CardiologistSimple86@reddit
How can you show it requires less maintenance? No one cares or pays attention to things like that in my opinion
bwainfweeze@reddit
Production outages and deployment delays. It helps to be good at RCA to make the story make sense.
CardiologistSimple86@reddit
But that’s bad because you make someone else look bas
bwainfweeze@reddit
The currency among developers it trust. At some point you have to outvote the person who is making more work for everybody later on. They are bad, you're just showing them for who they are.
CardiologistSimple86@reddit
But some teams don't care if they're making more work for everyone else because that's exactly what they want. They want more work for everyone on the team because they're struggling to find the problems they're supposed to solve.
GaTechThomas@reddit
Git history. There are tools that show git repo churn - that is, how many times a file has changed. These sorts of metrics are most useful for seeing trends, less so for a single data point.
jl2352@reddit
Most leads are poor at organising and prioritising their teams. They are poor at communication and moving quickly.
Most staff engineers are isolated nomadic mid level ICs with poor people skills. They were ’rewarded’ with a staff engineer role for staying so long, as their poor people skills meant they couldn’t be a lead. They wonder around doing whatever the fuck they like, which often has little benefit other than creating frustration for teams. Their primary skill is knowing the shitty systems (they built) inside out.
Senior management, especially at C-level, absolutely does matter. Their behaviour trickles down into the culture on everyone below. That’s why sub par senior management is so frustrating. Other teams are blocking you and doing poorly because the senior management is poor at leading a direction.
Most of all, success ultimately comes down to people. How well do you get on? Including with senior management. What are they like on a personal level with their interactions. That has a bigger impact than anything.
CardiologistSimple86@reddit
It doesn’t, it really doesn’t. Being good with people as a junior IC just means you make up for the shortcomings of your tech lead and manager, and they arrange for you to get fired while they line up their next promotions. There’s no benefit in being good with people at all unless you’re lucky
darkslide3000@reddit
How little we still care about stuff because we burned out years ago.
BamBam-BamBam@reddit
Fight Club, duh.
racefever@reddit
Most of your shitty plans don’t include a reasonable deployment strategy. Lots of deadlines are missed because people don’t understand that shipping > *. These days I don’t argue and simply ask about them. Most of the time no one has a clue. So I get that sorted.
Another thing is any senior that doesn’t know the politics me the workplace/team/department is just a junior who learned how to code. If you don’t consider the politics for your overall strategy then good luck.
Main-Drag-4975@reddit
Every unit of code should tell a story. It usually doesn’t, but it should.
FinestObligations@reddit
Is there any open source code base that does thi well?
Abject_Parsley_4525@reddit
Same. My personal view is that every piece of code has to justify its existence. Some code, or a lot of code, is just shitty slop that was done because needs be. Some code is really beautiful. It's rare for any codebase to be completely filled with beautiful code unless it's some pet project or not that important. I find the moment something gets hooked onto any kind of timeline all of these aspirational things just go out the window.
bwainfweeze@reddit
Should tell a story about the problem domain.
I’ve seen too many castles in the clouds that tell an interesting story but have almost nothing to do with the problem domain, so it’s a 200% problem for everyone but the author.
My usual response is, “that’s interesting, but what’s it for?”
yxhuvud@reddit
The first time something is solved the code is usually just a brain dump of the problem space. Then you open up the file half a year later and it is just a gnarled mass. So you spend a day untangling it. The next time you open it, the same thing happens.
Unless you make a point to always spend a little time cutting away the brambles and improve on the story telling part of the code. You don't have to rewrite the whole of it - just fix some small things so that it is easier to understand the next time.
When done repeatedly over time these small improvements really add up, and having fresh eyes is really the best way to see what needs refactoring.
Roonaan@reddit
Frontend development has not seen innovation in a decade or so.
thodgson@reddit
Amen. Yet, we see the introduction (read: revamping of ) a new front end language/script on the daily (almost...at least it seems that way).
bwainfweeze@reddit
Fire and motion.
thephotoman@reddit
Test exclusions.
We don’t talk about them because managers want to see 100% test coverage. The issue is that 80% test coverage is fine in most cases, but you can make the report say 100% test coverage if you take the 20% that doesn’t need testing, segregate it into its own package or artifact, and exclude it.
We don’t talk about what to exclude because we all know what needs to be excluded fairly instinctively.
bwainfweeze@reddit
Testing is about being confident with your changes. And you can be much more realistic about that confidence with 80-85% code coverage than with 100%. Because 80% can be reasonably achieved without playing games to boost coverage but not testing. 100%, unless achieved over the course of years, is an exercise in creating unknown unknowns out of known unknowns.
Once you hit 80% it’s better to do about 25-30% of the remaining code per year. And I don’t mean 5% each year for 4. I mean 5% the first year and 4% the next and so on.
TheGonadWarrior@reddit
I will do everything I can to NOT write code to solve a problem first.
bwainfweeze@reddit
That said, exploratory programming is a form of “build one to throw away” and we are systemically allergic to throwing away code.
Affectionate-Cod-457@reddit
Why is my brain working so hard to understand this post?
Delicious_Spot_3778@reddit
Writing in c++ does not make you leet. Understanding the trade offs between languages makes you more inspired than holding fast to your desire to write code down to the metal. This isn’t to say c++ (or rust or whatever) doesn’t have its place, but a majority of tasks should probably be performed using a different, less hardcore, language.
thephotoman@reddit
Also, don’t write language A code in language B.
I don’t care which languages you’re talking about. It’s usually possible, and also usually a bad idea.
Suepahfly@reddit
Every line off code you write becomes legacy
thephotoman@reddit
Or it gets thrown away quickly.
Rumicon@reddit
The simple most straightforward solution is usually the right one. Introducing complexity needs to be backed by evidence. “Best practices” and “on principle” is not engineering its cargo culting. You design a solution based on cost vs benefit and dev time is a huge cost you need to account for.
Was recently in a debate about whether we should do a network request or be building out the system needed to fetch and store local copies of the data we needed. But nowhere in the debate did the other side offer any material evidence for why a network request was worth blocking the feature for. They just opposed it on principle that it’s less performant than reading from a local db. That is true, but we’re surfacing this data on an internal admin that’s already slow enough that the user is not going to even notice the latency.
Engineers build for tolerances and constraints. We dont build to the cutting edge of weight tolerance for a pedestrian bridge over a river. A pedestrian bridge is not expected to transport tanks across it. They’re designed to handle human scale weight while keeping costs under control. That’s engineering, but in software we often get into needless debates about whether a pedestrian bridge system could handle the weight of tanks, even when it would never expected to do that
Tufnels_Protege@reddit
100% test coverage is a vanity metric.
got brought up in a meeting recently and stuck with me hardcore.
jenkinsleroi@reddit
Separation of concerns
thodgson@reddit
This.
fhadley@reddit
The vast majority of design decisions can be revisited at a later date. Working on the same problem for an extended period beats job hopping if you're optimizing for day to day satisfaction and not TC. Oh, and grug is right
omz13@reddit
Most of the things that you are developing are, in reality, completely pointless and useless; you are not making the world a better place.
BehindThyCamel@reddit
Or, even worse, they are deliberate enshittification. I have, in fact, for a short time been in a project that would make things worse for a specific group of one of our customers' employees. Nothing truly unethical, more like "well, when you put it like that", but still.
omz13@reddit
Truly unethical is a very personal setting. I have certain lines I will never cross. Too many people saying something is not too unethical is how enshittification happens and continues to happen.
BehindThyCamel@reddit
I have to agree with you on this. My ethical measure in this case was that a) it could occasionally introduce some inconvenience to the employees in question and b) only when I voiced what I thought of the idea to my coworkers did they see it that way, kind of.
You made me wonder what would happen if I reported the product to my company's compliance office. I don't think this is covered by our internal regulations in any way. (And I don't think we had a compliance office back then.)
Old-Outcome-8731@reddit
As a webdev working on enterprise projects, it doesn't matter what's trendy. I've haven't used any of the most popular technologies for a decade. All my core skills now were convincingly voted unpopular or dead. Didn't matter.
miyakohouou@reddit
This is one I’ll slightly disagree with. I think you’re probably getting at the “works on my machine” thing, which is bad. That said, making sure that software does run locally for everyone and thinking about developer experience are both important for productivity and working effectively so I think those things are in bounds and often framed in terms of “my machine”/“your machine”
messick@reddit
> Full test coverage
Perhaps you'll meet some actual experienced devs someday.
FinestObligations@reddit
If I was hiring a senior and they were adamant about full test coverage it would flat out be a ”no hire” from me.
messick@reddit
Sounds like a win/win
meatsting@reddit
Had one of my junior devs throw a fit demanding perfect test coverage. I told him this particular code base will never be used again. 1 year later and it’s long forgotten never to be heard from again
Schmittfried@reddit
I understand none of your examples except for full test coverage (if you mean the goal of achieving it).
To answer your question: Nothing. I don’t think there is any topic that will not be talked about at all with more experience. But formatting would be my prime example of a topic becoming less and less important.
Due_Musician9464@reddit
This is not the ideal scenario. But at several jobs, I learned after a while that my actual job was posting confluence/wiki/doc pages about my coding, not the actual coding. The managers cared about accountability, not whether the program was great. They didn’t even use the program to test it out.
Realizing this made me appear like a much better employee to their eyes. I started getting compliments about how productive I was. It took me way longer to code anything, no one ever read the pages again. But I was “better” at my true job.
geeeffwhy@reddit
being able to write English well is probably more important than whatever language you think is the skill that makes you valuable. I mean, you need both, but writing clearly isn’t even just about communicating well, it’s about thinking well.
other languages count, but if we’re talking professionally right now, English, motherfucker, do you speak it?
remington_noiseless@reddit
* Most code reviews don't review any code.
* Almost all code you write will be useless 5 years after you've written it. However, a small fraction of code will be in service for decades after it's written.
* A surprising amount of code never makes it to production.
* Most successful companies are successful by accident. The people running companies are surprisingly inept at business.
777777thats7sevens@reddit
IME code reviews follow an 80/20 rule. 80% of reviews are for things that you could essentially rubber stamp because they are straightforward and uncontroversial, so they take up 20% of the effort. The other 20% of reviews are for things that are more meaningful and should get a lot of effort.
Actually I'd even say it's more like 98/2.
seven_seacat@reddit
Right place, right time, right people. You need at least two, and most successful companies miss the third one.
remington_noiseless@reddit
Spot on. I once worked at a company with all three and it was amazing what we managed to get done in such a short amount of time.
jonnyboyrebel@reddit
If a project is not working out, either not making money or not improving productivity, end it. Make the call, turn off the servers and walk away.
Surprisingly, junior and experienced engineers find this easy to do. It’s mid level engineers that get overly attached code and find it hard to dump it when asked. Probably due to the time and effort they put into something just to see it in the trash.
Juniors don’t know any better, and experienced have already been hurt too badly by over attachment.
wesw02@reddit
You don't need to abstract everything. Just because two components do the same thing right now, doesn't mean they'll always be the same.
757DrDuck@reddit
If we mentioned it here, we’d be discussing it.
Wishitweretru@reddit
You probably make more than your immediate supervisors, and that getting “promoted” isn’t a clear concept.
Being director of whatever, or VP would mean spending your days talking to less interesting people, about banal aspects of products they won’t really understand.
NoobInvestor86@reddit
Ngl, OP you sound full of yourself
thecodingart@reddit
How shitty Big Tech’s codebases are and how the engineers are subjected into the most useless and unhealthy skills sets drained of common sense
panduhbean@reddit
Tell me more, I'm interested in validation of my spiteful assumptions and hate of leetcode
Unlucky_Buy217@reddit
Nothing to tell here, business features means devs have limited time and have to use all kinds of shortcuts to deliver. Which I guess is ultimately okay like someone else on the thread commented, that's what pays you money. It comes at the cost of shitty breaking code.
DeterminedQuokka@reddit
Just open the console in Gmail…
seven_seacat@reddit
If you're the smartest person in the room, you need to find a bigger room.
Creaking_Shelves@reddit
If you invest enough time in the practice of writing clean code/architecture, it becomes as fast as "quick and dirty".
SmartassRemarks@reddit
How critical reading comprehension is. I would say it’s about as important as coding skill, with just as much variance across people. Reading comprehension is critical for speed and quality of self driven learning and async communication, both of which are critical parts of this career for everyone.
Also, the importance of writing. Writing is a really effective way to audit your own ideas and get to a clearer solution faster. Writing allows you to really wrestle with your ideas and notice which ones sound stupid. In turn, writing can encourage others to read. When you read something well, which was also written well, you have the time to really chew on the ideas and let them land.
a_mandrill@reddit
No "unprofessional" looking code comments are allowed anywhere. I got caught a couple of times!
grahambinns@reddit
I worked for a company once whose comments got leaked after someone started poking around their project binaries (a python app wrapped in a Qt shell).
Luckily the leaker stopped tweeting the comments out, otherwise it could definitely have ended up in sackings and / or loss of contracts.
Rakishamon@reddit
Ego
My way or no way
And my favorite Comfort zone, its beautifly outside if it, scarry but beautiful!
Why write monoloth and get conflicts when working on different parts of app, why use older frameworks with vulnerabilities older language support if you could use new stuff with proven better performance impact....
DrNullPinter@reddit
Recently I will have and solve a problem that is complex and specific to my code base and industry, I know there’s zero chance ai gets close to solving and I think about coming here or the vibe subreddit and say this is an example of why you need to put in the work to understand what you’re doing but then it passes and I gbtw
CW-Eight@reddit
The Fight Club
feketegy@reddit
I wrote a blog post about this: https://primalskill.blog/opinions-after-20-years-of-software-development
to0ns94@reddit
Documentation. Take notes.
riversilence@reddit
Fight Club.
Flaeroc@reddit
Hey hey. Shh! Don’t talk bout it
NotMyGiraffeWatcher@reddit
Most of we think matters, doesn't.
The only things that matters is creating software that solves the problem, doesn't break and can be maintained
All the details, clean code, diagrams, tickets, dry, tech stack, agile kanban. Best practic, testing, optimization, etc..
Are all details that should be learned and then ignored when they get in the way of delivering.
mattk1017@reddit
True, but doing those activities is in our best interest. First, it keeps the job far more interesting — if I just churned through one ticket to the next doing the bare minimum, then I wouldn’t enjoy my job as much (no hate to those that do the bare minimum, but it’s not for me at my current stage in life). Also doing those activities keeps you more employable. For example, your current employer might treat testing as a “nice to have”, but your future employer might treat it as a “must”
janyk@reddit
You're right, but details like clean code and testing are what get you "doesn't break and can be maintained". Without them you'll just get "solves the problem", and even then it's only a big "maybe".
budulai89@reddit
We don't talk about general career advice and low effort posts.
MinimumArmadillo2394@reddit
And sometimes, we dont get to talk about tech career advice on a high effort post because a mod just decided your post was not enough about tech...
AndYourLittleDogToo@reddit
Feck off
We don't talk about effort on a Friday night
triple6dev@reddit
It is mood.
engineered_academic@reddit
How I love to code in my free time and look at all this free work I did for my employer.
ccricers@reddit
Local B2B agency work and the experiences of working in one
These jobs are almost existent if you were to believe Reddit. but every medium size town and larger has at least one or five businesses like this.
No one really asks "I got offers at Spinx and Webconsuls, which would be better for me"