5 ms·
1. X that is a good idea for solving problem P appears on the tech scene 2. People who have problem P pick up X and say good things about X 3. People, usually
by kozikow 10y ago
1. X that is a good idea for solving problem P appears on the tech scene
2. People who have problem P pick up X and say good things about X
3. People, usually junior devs, read blog post about X. They start treating X as solution to every problem they encounter and ofter take it to the extreme.
4. After realizing it's not helping, they blame X and write posts like this.
You can replace X by many things, starting from methodologies like microservices or TDD, ending on things like nosql databases.
- Jtsummers 10y agoJunior devs and managers.
- partycoder 10y agoThe problem is how you define a junior developer. A guy with 30 years of experience that has only exposure to imperative programming, and never really learned OOP, networking, functional programming (it's not new: lisp, scheme, haskell, etc. have been around for decades), never really learned about operating systems, never really cared about automation, testing... unless you work on implementing software at a low level, which is very rare these days... guess what, that guy has a lot to learn from a fresher engineer, or engineers that actually cared about learning.
- kozikow 10y agoMy point was not against new technologies. It was against religiously applying them everywhere without reasonable judgement. Since you brought up functional programming, it actually fits the same framework. In that case P includes problems with a "pure" domain (e.g. compilers) or problems that require lots of multi-threading. It does not work well for problems that are fundamentally state-full or sequential. It also does not work in "messy" domains - e.g. data mungling.
- partycoder 10y agoReasonable judgment is fine. But reasonable judgment can be applied to everything, including who is better suited for making decisions about technological adoption. Someone who is biased towards "getting job done" and seeing technology adoption as a mere distraction, is simply too biased to be of any help during decision making. When evaluating technology adoption, you need to see the pros and cons (including adoption costs), and evaluate things seriously.
- reinar 10y agolol what I think it's junior ones who lack understanding of how is OS and networks are operating, as they don't needed most of the time in more popular industries (mobile development, web, etc). source: by the chance I conducted few interviews for software engineers and devops in web industry - and instead of fizzbuzz I started with asking what's the difference between TCP and UDP. Results will surprise you (also too many people want to exploit current hiring system by just cramming algorithms).
- sotojuan 10y agoThe "intermediate beginner" who latches on whatever is "new" and trendy is my biggest annoyance with the industry. Unfortunately functional programming seems to be what at lot of these people are claiming is the solution to everything now, even if they have little experience building systems with it and it's older than OOP.
- pitaj 10y agoI hate to go on a tangent, but what are some examples of things that OOP does better than FP? I can only think of a couple examples: data structures and some APIs.
- sevenless 10y agoAnything that behaves like an object, would be the obvious answer. GUI elements, things in games or simulations. More abstractly, an object's a namespace with persistent properties, so for something that has a persistent, possibly mutable, state, an object is the metaphor you want. Whether data structures should be objects rather than primitives depends very much on the data.
- stickfigure 10y agoErm... pushing data structures between APIs is the essence of countless viable businesses. I love both FP and OOP and especially love using them together. I honestly don't get these arguments.
- sotojuan 10y agoI think what frustrates me is that I see these people as, for lack of a better word, "posers". I'm no functional expert and I'm just in the beginning of my career, but I'm very skeptical of devs who had little problem with imperative/OOP code suddenly writing Medium articles saying OOP is dead and "functional" is the "next" step. Just makes me uncomfortable, but I'm learning to ignore it.
- pitaj 10y agoIt wasn't an argument. I was asking a real question I am curious about.
- aikah 10y agoEnough with that bullshit. > junior devs mostly don't make architectural decisions. It's a bit easy to keep on blaming "junior devs". Who keeps on hyping up and marketing useless stuffs ? that's not "junior devs", that's big consultancies that want to sell their crappy services, that's PAAS that want to sell more servers, that's vendors that want to sell more useless stuff. Enough with blaming "junior devs". Junior devs don't lead teams and have very little say when it comes to architectural choices, they don't contract this or that consultancy, they don't decide whether a business will run on Amazon or Azure. Junior devs didn't invent NoSQL, Microservices, "Serveless" and all that bullshit. Well established players sell these services to others, and the people who drink the kool-aid are managers, not junior devs. Do you really think "junior devs" want to maintain 50 micro servers just because it's trendy? when they could get away with a single one?
- sotojuan 10y agoHeh, you describe me exactly. I'm "junior"-ish and the second to last place I worked at was microservice, a ton of Docker, and MongoDB. Definitely wished we had a simple monolith with Postgres instead.
- ffggvv 10y agoThank you for defending me/us :) Whenever there's bullshit talking at my company I always make a "meh" face and try to bring to the table the negative sides of a solution.
- sadlion 10y agoDo you have any advice for junior devs for assessing architectural decisions and crappy services?
- tbrownaw 10y ago3. People, usually junior devs, read blog post about X. They start treating X as solution to every problem they encounter and ofter take it to the extreme. Another possibility: senior dev / architect wants to try it on a relatively small project, as a pilot to get a better feel for how it works and where it might be useful. Sure it might cause headaches and extra cost on that one project, but the knowledge gained might be worth it. The resulting blog posts are either public dissemination of that knowledge, or griping by people who either aren't interested in that big picture or who think the cost/benefit call was made incorrectly.