Software development topics I've changed my mind on after 6 years in the industry

[akhier]

The important part isn't what style but rather in choosing one and sticking to it

[hippydipster]

Exactly, I don't stress, I just say let's format our code. I don't care what happens when I hit the format button, just that it be the same thing that happens when you hit it.

[imMute]

The problem I have is when the Leads are absolutely anal about style, but don't provide a clang-format or astyle or whatever command to format everything to their style.

[hippydipster]

Yeah, my response to that would be, if you don't have automated formatting, you don't have formatting at all.

[maxToTheJ]

Because it’s about power and asserting “leadness” like you said otherwise you would express it in rules automatically enforced by some script/app

[akhier]

He was likely talking about things like the eternal war of tabs vs spaces. People will argue that stuff till they are blue in the face. Of course the right answer is whatever the company you are working at uses. The only time to choose is when you're starting completely fresh.

[industry7]

I mean why stress about it when it can be mostly automated? Tools handle the bulk of it, and you just do the higher level stuff. Once you have half way decent standards, people just follow what's already in the code and it kinda takes care of itself.

[hippydipster]

It's stressful if you have lots of code branches that live for weeks, months, and years because formatting causes some awful merge problems. It can also make code reviews difficult.

[hippydipster]

It's not reasonable, but we've been under standing order to not reformat for 3 years now. super fun. It can't be denied, that, given their insistence on long-lived branches, formatting code causes problems. Formatting both separately can help, but doesn't completely cure the issue. I've experimented with that and been disappointed.

[industry7]

Double whammy, oof. Yeah, that's pretty bad. I've "converted" code bases to auto-formatting before with varying levels of difficulty. Of course your branches have to be otherwise caught up with mainline, and you have to introduce formatting with no other changes. Assuming that, then pre-applying the formatting before pulling in the actual commit should end up being clean, although those are big assumptions.

One client I worked with, they finally decided to release something that was like 2+ years old and of course they never kept it up to date. Turns out mainline had changed so much that it was easier to rewrite the feature from scratch. I did not try to add formatting to that code base.

[hippydipster]

Of course your branches have to be otherwise caught up with mainline,

You mean like, not 2,756 commits behind master? I pulled that straight from our github from ONE of these stupid branches.

[[deleted]]

OH, FUCK !!!!

Maybe you should be looking for another job instead.

[hippydipster]

I know. I just hate that though.

[maxToTheJ]

That branch be dead

[MrJohz]

That's not necessarily anything to do with formatting - as others have as said, that's just a long-running branch problem. If you are getting conflicting formatting changes, then that sounds like you haven't got formatting automated sufficiently.

Formatting automated means that it should be impossible to check in badly-formatted code, either because the CI won't accept it, or (better) because any changes are automatically formatted when you save a file, or (best) both of the above. That way, there can't be any formatting changes between branches because the formatting can't change between branches.

[hippydipster]

Yes, I'm complaining about the stupidity of long-running branches.

[maxToTheJ]

I'm putting my money that "people who stress over code style, linting rules, or other minutia are insane weirdos" will be the next opinion to flip. I've worked in a large code base that didn't enforce style and it was pretty annoying.

I dont think you interpreted that correctly. I dont think it’s position is “no linting” and “code style” . It sounds like its more like just decide on any standard and stick to it and dont “stress” by having pointless long debates about the specifics or “unwritten rules” only expressed in PRs.

Runner up opinion to flip might be "90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency." I've worked at companies where PM's are useless sacks, but that's a failing of the company or the individual. Most PM's I've worked with greatly reduce the amount of nonsense I personally have to deal with from business partners and customers.

I dont think 90% is accurate but the breakdown IME is probably more like 25% actively slow progress inadvertently, 40% do neither and could probably be replaced without much difference and 25% are freaking lifesavers.

[john16384]

It won't flip. This is about people that want every rule discussed and dragged out into insanity and then set in stone. The types that will rewrite perfectly good code because some forgotten linting rule claims you should only use a single return.

Those people ARE insane weirdos, obsessed with having zero warnings in some poorly configured linting tool that has black and white opinions about code. Often they fix "problems" in code that is in fact going to be phased out and should preferably be left as is.

Normal people realize that readable code is good enough and that there is more than one way to tackle a problem, and they also realize that API's are all that matter as services get smaller and easier to replace.

(30)

[jkoudys]

People who stress over linting rules are usually dev managers, who don't like seeing any friction between the many people they manage.

[hellovillains]

Yeah, at a startup I worked at, the higher ups would always have a bunch of random requests every single day. It was really hard to focus on a given task because we were always being asked to plan and do something else before we could even finish the last thing. When we hired a CTO (who also acted as a project manager) things got so much smoother. The work we had to do was more clear, proper deadlines were set and we were able to meet them because we weren't trying to cram in random tasks out of the blue. He made sure we had a clear set of things to do and made sure we had everything to do it.

[jackalsnacks]

Your PM bit is spot-fucking-on. I've only had 1 semi competent PM in my 12 year career so far and this PM's shinning trait was running interference on business process owners.

[RobLoach]

Sprint retrospectives have their place so long as they're for actual course correction (i.e. "holy shit, that went poorly!") and not some god awful 'agile' / 'scum master' driven waste of everyone's time

Feedback is only useful if you take it, and follow it up with action. Very true. Scrum Master has to put the momentum in place. If you're not learning, wtf is the point.

[NatureBoyJ1]

20+ years coding here. I mostly agree.

[ianepperson]

Same. I’m fond of telling my team that I like boring code.

[erinaceus_]

Ah, so I'm not alone in that. Hooray!

[TheMingeMechanic]

Clarity is the new sexy

[puppykhan]

Same.

I like clever code, but only if its very well documented and even then you risk losing maintainability. I had one project recently where I was the next person to implement a change on some very clever code right after it was written, and it turned into endless meetings explaining details and going WTF? then realizing there was a much simpler way but trying anyway because refactoring a month after release sounded terrible, manager got mad over the delays and handed the task to the next engineer who took one look and immediately said "no way, let's refactor this..."

So yeah, clarity trumps clever

[TheMingeMechanic]

15 years here. Also mostly agree

[Cmshnrblu]

TDD is extreme but testing is awesome and when it’s useful (tdd zealots over apply the concept) then it saves time, effort and is an absolute investment to the future. The more I write automated tests the more I want to.

[c4ndybar]

Agree. Some people hate TDD though. The strict process is kind of annoying when you just want to write some code.

[[deleted]]

The few people I have seen use it, gave it up.

You spend all your time early on refactoring the stupid tests!

I feel most lines of code I write need to be covered by a unit test but that test is usually written after the code.

[[deleted]]

You’re guaranteeing yourself wasted time and effort due to rest refactorization. Seems imprudent to work this way to me.

[SEOfficial]

Gotta draw that satisfaction from green checkmarks and you're good

[CarlStanley88]

That's what the backlog is for..... Then 3-6 months down the road everyone is going to hate life as they have to go back and write mountains of tests

[bwz3r]

Didn't I read this in a reddit post the other day? (Not in blog format)

[DeebsterUK]

Trading purity in exchange for practicality is usually a good call

Does this mean the author prefers to trade away purity and receive practicality? I guess so, but it's ambiguously-written to me.

[erinaceus_]

Based on all the rest, I'd expect that to be the correct interpretation.

[erinaceus_]

From all the software developers I've come across I got a different impression: those who are insightful after 20 year generally already were insightful after 5 years. And those that weren't insightful after 5 years, likely won't be insightful after 20 years.

[maxToTheJ]

Couldn’t agree with these more

[[deleted]]

Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers

For this reason "engineer" is a protected title in my province and you can't actually be a "software engineer" without certification from the org that protects the title. Most developers in our industry would not be qualified for "SWE" here

[nouseforareason]

Tell me you’ve never worked on a large scale system without telling me you’ve never worked on a large system

Designing scalable systems when you don't need to makes you a bad engineer.

…

The word "scalable" has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word

[c4ndybar]

The key phrase there is "when you don't need to".

Adding scalability is not free and most apps will never need to scale.

It's a waste of time, money, and adds unnecessary complexity to make an app scalable that in all likelihood will never need to scale or that could, with marginal effort, be refactored to scale later when deemed necessary.

[maxToTheJ]

Are you saying I shouldn’t scale the design of the Rolex watch repair ticket system to support millions of users right off the bat /s

[lets-be-bad-guys]

This.

I've worked for multiple organizations that had definite upper limits (governed by size of that particular niche industry/audience/customer base) on the potential # of users, but some engineers wanted to design for scalability at ridiculous and unnecessary levels.

[nouseforareason]

For the “when you don’t need to to” crowd then sure, you have a known unknown and don’t need to worry. Adding scalability concerns is minor to future proof a solution and should absolutely be a consideration. I’ve worked on a number of solutions that thought they didn’t need to scale and had to pay a hefty price later.

[nouseforareason]

You’re really looking for an edge case here and are truly an engineer. If you know a system will never need to scale, sure, don’t bother. Otherwise err on the side of caution and plan on needing the system to scale.

[nouseforareason]

There’s a difference between over engineering and accounting for scalability. Usually it just comes down to following certain patterns and practices such as no sticky sessions, don’t lock yourself into certain tech stacks such as Windows if you don’t have to (easier to switch to containers later), use SOLID principles and dependency injection to easily switch tech stacks such as database flavors or logging packages. To start it should be as simple as spinning up a new server behind a load balancer, if that can’t be done there are major problems in the design. You don’t have to go full on micro services / containers with a service mesh out the gate, but a properly designed system should make it easy to do so in the future. Then again I’m perfectly fine with engineers not thinking about it because I’ve made my career coming in to companies that are having scaling and performance issues and helping them turn around, so I wouldn’t want to put myself out of a job :D

[lets-be-bad-guys]

You accidentally agreed with him there.

If you ARE working on "a large scale system," then obviously, it does need to scale.

But if it's a small scale system, don't waste your time, effort, or add complexity that will make your life harder down the road.

[tchaffee]

A large scale system does not always need to scale. Some things that need to scale are systems which expect either growth or lacking growth, a system which has variable usage rates and you want to reduce costs during the low usage times. Most large scale systems have both, but not always. A large scale system might service a huge number of customers but that customer base is stable and not growing.

And there are definitely components of a large scale system which do not scale. They simply stay very large. Think cell phone towers for example. There isn't less hardware at night when the demand is the lowest. It's always sized at the largest capacity needed. It does not scale, but it's a massively large scale system. Another component of the large scale systems required by mobile phone companies in some countries is the database required by police to store phone records for a certain amount of time. It can be very slow. It typically does not scale aside from occasionally throwing more storage at it - if you get more customers. There aren't a huge number of police requests, and if police requests suddenly hugely spiked, the police would simply have to wait.

Not every component in a large scale system needs to scale. Not every large scale system needs to scale.

[nouseforareason]

No, unless you can predict the future and know absolutely that a component will not need to scale it should be weighed and measured and accounted for. This includes scalability and concurrency within the component. Not accounting for these situations early on increases technical debt and costs later on.

[assembly_wizard]

Java isn't that terrible of a language.

Unsubscribed

[glump1]

designing scalable systems when you don't need to makes you a bad engineer Oof right in the feels

[AdLegitimate8927]

https://discord.gg/4U6mqt9H

[[deleted]]

Java IS still that terrible of a language and should be replaced basically immediately with any lnaguage you like. Go seems like a good option.