18 Rules of Software Engineering.

#dev #developer #programmer #software #engineering

@mookie That's a pretty solid list!
×

18 Rules of Software Engineering.

#dev #developer #programmer #software #engineering

@mookie I love how it starts at 0️⃣

@SeaFury

Proving the list is legit!

@mookie That's a pretty solid list!
kerravonsen | Use The Source, Luke

@mookie when building a framework, keep your resume up to date
@mookie @cmsdengl
AI code suggestion systems follow NONE of these.
@mookie
18. There are no rules. Only guidelines…
@mookie That used to be good rules, but now they've added another one: "18 - Haha, just joking. It's vibe coding now"
@mookie I'd prefer 7 to say "constrains arguments" rather than prevents them, but that's probably because I've never seen a coding standard that I'd personally adopt.
@mookie
I would suggest also :
19 Get the spec nailed down
19b Beware feature creep

@mookie it's missing at least one rule :

-1 : beware off by one errors

@mookie coding standards do not prevent arguments. i'm still mad at everyone who thinks two spaces are in any way superior for indentation to tabs.

@mookie

Some pertinent points in relation to this at the corporate where I am employed and why I don't want to do it anymore:

5. The problem is that you have poor hiring decisions and their inexperience shows in the "freshly minted graduates" writing garbage

10. These are used to reprimand developers and/or gaslight them

12. Asking for help unleashes a lecture "why are you doing it that way, instead of our way? Where's your documentation, what are you doing during the day here?" and then puts you in a pair-programming setup.

15. Say that to my manager, see how fast you'll get written up or put on a PIP

@mookie

Ich bin der Geist, der stets verneint.

0. You will regret that simplistic design when the real world calls.
1. Nobody takes pride in what they write.
2. Everything is "good enough", there is nothing excellent.
3. Nothing gets made to fit, everything has to come from some "proven framework".
4. The wiki is filled with half-assed bullet points except the bullets are Markdown headings of various sizes.
5. Nothing ever gets fixed properly, only wrapped and worked around.
...

@mookie
6. If it's not supported by the framework, it can't be done.
7. The rigid and overbearing "coding standard" is the subject of recurring arguments at lunch.
8. Commit messages are a swamp of self-righteous overexplanation why the previous code sucked.
9. When the boss decides that something is the new hotness, everyone better play along.
10. Code reviews quickly become a device to establish pecking order.
11. Most code is long-winded boilerplate that The One IDE knows how to refactor.
...

@mookie
12. Two people bog down an entire department by their incessant inability to RTFM.
13. Every "project" that aims to "get to the root" of something immediately devolves into bog standard fire fighting due to some technical or budget constraint.
14. Software is never completed.
15. Estimates are always treated like promises.
16. Every feature gets rushed out the door, the product is never in a coherent state.
17. Nothing. Is. Absolute.

SCNR.
all in good fun. ;)

@mookie Is there a reason most of these statements aren't closed? Or is this meant to be a cascade list?
@mookie I would add some more like:
18 - don't build fancy stuff, solve the problem
19 - think about security and testing from the beginning
20 - wear your programming socks

@mookie Microsoft and Redhat disobey this on a monstrous scale.

To be better than them at coding is in this way is to be above water.

Another words, -1 or worse for their methods. 0+ for anything better.

Those two corporations are heinous when it comes to complexity and obscurity.
"Systemd" after all...

dbus too, etc...

And in microsoft's case particularly, "Windows"

Windows btw, is a good name for it, except they don't mention why.

Your OS can be seen from afar by them.

"Windows"

:P