[Philosophy] SE, Why we don't do it correctly ?
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". :kekw: 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 !
47 Replies
⌛ This post has been reserved for your question.
Hey @FirasRG! Please useTIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here./closeor theClose Postbutton 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.
- 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
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)
Who do you consider spreading a bad mindset? Customers and managers? It has always been that way.
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 outsure
they were teaching you to care about architecture to shoot yourself in the foot
but when a senior wants to support them by showing what should be done first concisely
they get into some troubles especially with managers
managers have always been a problem - and it will always be that way
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)
It sounds like you describe some disfunctional company.
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
i.e. many companies we have
What about it?
no source on web
If you aren't careful, you'll shoot yourself in the foot - it's simple as that
except wikipedia
?
which is really weired
Yeah, my perspective is pretty skewed because I already know how to avoid bad companies.
I have no idea what you are talking about
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.
i mean, i think that those acronyms are essential to learn, to remind , to update (as IT evolve everyday)
kinda, depensd
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
What else do you expect?
Also there are many books about these things
my question is : why frameworks and libraries code are heavily documented
why the core of the IT aren't well documented
because the devs realize it's important and many people look at it
but there is something more important than that
like those acronyms
and there are others like Demetry, liskov, brooks law
What do you mean with that?
and they aren't discovered by anobody , except some occasions
the core of the IT means the principles like SOLID (which is popular ig)
and there are many resources about it
i know, most are paid books or tutorials (like the ones on Pluralsight) but no opensource source
What?
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
So, you mean free?
maybe this topic is bit out of scope
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
The things you are talking about (e.g. SOLID) are things about how to write code
sorry if i interrupted u
so I don't see what confuses you
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)
You know you can follow SOLID without remembering exact terms?
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
so what?
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
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
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 liewhile 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:kekw:
it's not just IT
💤 Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.