[Philosophy] SE, Why we don't do it correctly ?

[noble tangle]

I've been thinking about this question for years, without truly finding the answer to it. In real world experience I've seen many engineers (developers, networkers, business analysts) from different levels (certainly most are juniors), most of the time where they get assigned to an issue or a task, they read description for maximum 30 mins, discuss a bit to clarify or add something in description, create their code branches and dive directly to code. Another example, I've seen it so much, in technical assessment tests, the employer of an organization, put the candidate into a coding test with very short timeout (like 15 - 30 mins), which means they want them to understand the whole problem very quickly and code directly with high expectations! A 3rd example, especially in medium and small companies, when they start on a big project from scratch, and a customer tells them "So i'm ok to start some business with you, however, i want a first working release in 2 weeks!" and they say "Sure ! don't worry". So they start coding blindly and do multiple mistakes as they didn't take enough time to think about the problem and at the end they lose the customer and the whole business, and they try again to find another to do same mistake and so on. I don't understand, really, why we learned in uni and e-courses that diving to code is the easy part, while thinking about stuff like architecture, maintainability and scaling is the hard part, but in practice we do the opposite ?! IOW, we think that coding is the HARD damn part, which is not true !

[pale cradle]

⌛ This post has been reserved for your question.

Hey @noble tangle! Please use /close or the Close Post button above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically marked as dormant after 300 minutes of inactivity.

TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.

[raven gazelle]

• Starting to code after "getting a task": Many things don't require that much architectural discussions and in many cases where juniors get some task to do, the architectural things are kinda already figured out
• interviewing: Well, they are looking for programmers and that's the easiest (and time-effective/cost-effective) way to do programming interviews
• customers: Well, that's a customer problem. But even for these things, it's important to think about architectural stuff.

I don't know what you mean with it being the opposite in practice. If you are asking what is the most work, then it's probably the coding part (which often includes many architectural decisions). But the other things are often other really hard decisions that can especially have a lot of impact

I wouldn't say one is harder than another though

For scaling: In many cases, you can improve scalability afterwards but it's often (significantly) more effort.

For maintainability: Yes, that's the hardest part of coding IMO

[noble tangle]

im talking generally, and it's typically about a spreading bad mindset imo

which means: through my experiences (community, company, freelance) any sort of IT specialist care alot about coding skills (even in design ui/ux)

[raven gazelle]

Who do you consider spreading a bad mindset? Customers and managers? It has always been that way.

[noble tangle]

but when i was a student, code was the least important thing

even in some big it books, famous authors remind that code is not the hard part of a software

in many cases where juniors get some task to do, the architectural things are kinda already figured out
sure

[raven gazelle]

they were teaching you to care about architecture to shoot yourself in the foot

[noble tangle]

but when a senior wants to support them by showing what should be done first concisely

they get into some troubles especially with managers

[raven gazelle]

managers have always been a problem - and it will always be that way

[noble tangle]

then when a disaster happens, manager calls senior for immediate help

alright, let put company managers aside, if we look at opensource projects, managers here are actually developers

but yet they behave same company managers , they don't give a shit to understand issues optimally

ive seen many issues in libraries and frameworks (except few ones)

[proud nacelle]

It sounds like you describe some disfunctional company.

[noble tangle]

**another issue **i didn't mention and it's really annoying to me: design patterns and acronyms such as SOLID, MVC, DRY, KISS, OO, MVVM, and so on

[raven gazelle]

i.e. many companies we have

[raven gazelle]

What about it?

[noble tangle]

no source on web

[raven gazelle]

If you aren't careful, you'll shoot yourself in the foot - it's simple as that

[noble tangle]

except wikipedia

[raven gazelle]

?

[noble tangle]

which is really weired

[proud nacelle]

Yeah, my perspective is pretty skewed because I already know how to avoid bad companies.

[raven gazelle]

I have no idea what you are talking about

[proud nacelle]

I don't think I've seen a manager making problems because some senior helped a junior with a task.

Like, that's the whole point.

[noble tangle]

i mean, i think that those acronyms are essential to learn, to remind , to update (as IT evolve everyday)

[raven gazelle]

kinda, depensd

[noble tangle]

but when i search on web about them, i dont find any good reliable source to take from it, except some articles made by unknown volunteers

[raven gazelle]

What else do you expect?

Also there are many books about these things

[noble tangle]

my question is : why **frameworks ** and libraries code are heavily documented

why the core of the IT aren't well documented

[raven gazelle]

because the devs realize it's important and many people look at it

[noble tangle]

but there is something more important than that

like those acronyms

and there are others like Demetry, liskov, brooks law

[raven gazelle]

What do you mean with that?

[noble tangle]

and they aren't discovered by anobody , except some occasions

[noble tangle]

the core of the IT means the principles like SOLID (which is popular ig)

[raven gazelle]

and there are many resources about it

[noble tangle]

i know, most are paid books or tutorials (like the ones on Pluralsight) but no opensource source

[raven gazelle]

What?

[noble tangle]

opensource means community to me, and i find it really weird as nobody cares to specify a reliable source website to introduce those patterns correctly and keep them updated with evolutions

[proud nacelle]

So, you mean free?

[noble tangle]

maybe this topic is bit out of scope

[noble tangle]

opensource = free to read and contribute

yes

to sum up i feel the most attentions are on code

not only from managers

and that's not good sadly

imo

[raven gazelle]

The things you are talking about (e.g. SOLID) are things about how to write code

[noble tangle]

sorry if i interrupted u

[raven gazelle]

so I don't see what confuses you

[noble tangle]

i know but if u ask a developer randomly what does the o means in solid , they will need to check google

which means they just know solid as a word

and i think this is problematic as it reflects the intern world of a developer (knowing that im a developer too)

[proud nacelle]

You know you can follow SOLID without remembering exact terms?

[noble tangle]

i know, but this would show something, as i said. and it's not an issue with someone specifically, it's about a mindset

this subtopic was simply a factor to the main topic of this thread

[raven gazelle]

so what?

[noble tangle]

im just asking and sharing the experience with you

as for your answers they are somewhat good to me

i believe that that's how we move forward

in fact i think about starting my own IT business and want to behave in the right way

as manager, developer, teammate, leader

[raven gazelle]

You might already know that but be warned: It will be a lot of work and you'll probably earn more money (especially more reliably) by being employed normally

[noble tangle]

exact

i hardly thought about this

and that's another problem actually

why management in IT has become so challenging ?

same for sales

but that's not all imo, cuz the whole stuff are connected

the company relies on its manager, who relies on the product managers or superiors and those rely on theirs developer teams

and those teams, most of the time enjoy diving to code

without much thinking

i remember few years ago i had a tough debate with my team (including team lead and manager) after having a serious conflict about actors in UML

i had to bring UML official documents to let them know that something has changed in UML v2.5

they were absolutely going to do some very bad decisions after being confused between some actors in architecture

they even didn't care about documenting use cases, actors, sequences, classes

but that wasn't my real problem 😄

cuz when i switched to another job, thinking it was better then the prev one, i had exactly same experience

somebody i trust, told me something funny :

my friend, look, you see those words "methdology", "planning", "thinking", architecture decisions, principles, patterns, etc.. are kinda lie

while i don't believe what they said, i do believe they have a reason to say that

a common methodology known as 12-factor, i think you already know it

i discussed it with team as it wasn't aware of it

I tried so hard with some diagrams and brief descriptions to show them how work should be done following this methodology, they fully agreed instantly

but when we went back to our offices, nobody gave a shit

we discussed about it later, and i asked if something is wrong, and no one complained

it's just that they enjoy to play with code

and stuff like these, in their eyes, are a waste of time and useless

sadly

even manager, who really appreciated the documentation (ive put it on a static website with modern design and some cool features)

told me :

the efforts u did are good, but it would be better for you to use it in code

[raven gazelle]

it's not just IT