wilson/thomaswilson-sveltekit
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

blog: why-no-oo typos

Browse source
This commit is contained in:
Thomas 2022-08-19 06:57:30 +01:00
parent d743f812bb
commit 80d062f474
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
src/content/blog/2022-08-18-why-no-oo.md
View file

@ -11,7 +11,7 @@ I am leading hiring efforts for my small engineering team. We're looking for ou
Our technical interview process runs some one-to-two hours and starts with a problem. Something invented but plausible for a small, operations-software hybrid company. We introduce the problem in fuzzy human-friendly words, and then spend the rest of the interview turning it into well-defined terms. We codify it. And then we code (some of) it.
I'm looking for for if this person has built quality software collaboratively with others: have they made sure they understood all of the messy meatspace malaise, and they can devise some precise presentable platonic solution. Did they use good people and then computer words to describe it.
I'm looking to see if a candidate has built quality software, collaboratively. Have they made sure they understood the messy meatspace malaise, and can they can devise some precise presentable platonic solution. Did they use good people- and then computer-words to describe it.
Because we give such a tangible problem, we really encourage our candidates towards using classes. Classes also happen to be really good at organising code together, so we also encourage them everyday in the engineering team.
@ -25,18 +25,18 @@ Experience writing and managing software can give you a good box of tools, if yo
In my darker moments I despair - why is no one doing OO?
Why have a quasi-random web software professionals repeatedly resisted one of the oldest, most common enterprise application patterns? I don't know. But I could make some cynical guess at notions of:
Why have a quasi-random group of web software professionals repeatedly resisted one of the oldest, most common enterprise application patterns? I don't know. But I could make some cynical guess at notions of:
* "my code should be able to handle any data, its the users job to do the sensible thing"
* "I don't want to couple my code too closely to the real world"
* "React uses functional programming"
* "OO is old and no one writes 'enterprise software' anymore"
* "it doesn't matter what I call things in my code, or where I put them"
* "it doesn't matter what I call things in my code or where I put them"
* "it's not cool enough?"
Frameworks (Rails, Spring Boot), architecture patterns (MVC, MVVM), Books (Domain Driven Design, Clean Code/Architecture) all put Objects, entities, or models right there.
Frameworks (Rails, Spring Boot), architecture patterns (MVC, MVVM), Books (Domain Driven Design, Clean Code/Architecture) all put Objects/entities/ models right *there*, obvious and near the centre.
They're there because they add value. Not to fill pages or as homage to bygone software practices. It's a competitive ecosystem, and evolution would select against them.
They're there because they add value. Not to fill pages or as homage to bygone software practices. Software engineering and computer science are a competitive ecosystem, and evolution would select against them if there wasn't _something_ there.
How is the industry producing young, competent, practicing professionals who can't model real world problems? Why is no one doing OO?
How is the industry producing young, competent, practicing professionals who struggle to model real world problems? Why is no one doing OO?