Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
Microservices, with my last breath I spit at thee.
The basic architectural principle behind them is similar to Unix apps, where you have small applications each with a narrow scope. You use plumbing to pull them together into complete systems. The idea is to break things into independent subsystems that are weakly coupled. In theory.
In theory if you observe the idea of having a narrow and specific scope while decoupling from the domain they have application. Certainly the play a big part in distributed systems.
Where they come undone is when they are tied tightly to the domain, sharing the data model. If this happens they either end up sharing the persistence mechanism, aka the database, and thus having a central point of failure, or having integration and query nightmares when you try to pull data together from multiple Microservices into a single coherent view.
As with many other areas they are adopted and implemented as some kind of silver bullet, but without a skeptical analytical approach to their implementation can turn into the classic Big Ball of Mud, where Microservice is piled on top of Microservice with little or no concern about clear architectural separation of concerns.
In my experience they become tightly coupled to narrow use cases and lead to an unmanageable explosion of code and nightmare of latency. Perhaps some companies have the engineering discipline to implement them right, but too often this isn't the case.
I may add that use of microservices makes deployment and maintenance much more complicated than it needs to be. And makes local deployment for testing/debugging at least very inconvenient (usually just impractical, often even impossible).
Possibly I know better solution than microservices, I've described it in my blog here, at dev.to recently.
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
I read your article. Looks good, if only because I have adopted something very similar. With Gravity there is dynamic runtime configuration which can create new data structures and related API. Business rules, views, filters and integrations are all defined at runtime through the API. It is a clustered system so that all the services run on each node, so regardless of the API called it is capable of servicing it without doing another hop. It uses JMS queues to manage workload across the cluster. Because each node of the cluster is identical you will never get resource bound on a specific service because any node can do anything. There are three clusters involved, the API, JMS and Persistence.
So true though. Most attempts for Microservices with no real value addition ends up with distributed monolith when the attempt goes ill planned. Especially small teams, attempting the route for the hype.
Yeah, I found myself on that bandwagon for a short time when Meteor came out. Very fun to work with, and the SPA idea is very attractive. But it adds a lot of complexity and some other issues that normally don't happen on server-rendered websites, and there are little pieces of different projects that can be made interactive without going full-blown SPA.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
WSL: yeah, I'd rather just use either Windows or Linux (and I do: Windows on company-owned laptop, Linux on my personal laptop).
OOCSS? I don't even wanna know...
Is WordPress overrated among devs, or do you mean vs. other blogging platforms or website builders? It's fairly easy to set up quickly, which seems to be why it has so much all-around support. But its DB storage is definitely bloated, and most themes I've used are loaded with gimmicks rather than being focused on performance.
So no, I don't care for it. Was just wondering what you meant.
Dark mode is a personal preference for me, but yeah, each person and work environment is different. "To each his own."
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Wordpress is ubiquitous but it's not very well made. It takes a lot of ideas from old-style PHP and just runs with them. People like Gutenberg but it just encourages storing chunks of non-semantic, non-transformable HTML in the database. People bolt things on and call it a CMS, but it's really not designed to be one.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I am a software development engineer in test for Infosys. My job is officially to write automated tests in Selenium Webdriver. I'm also a web developer as a hobbyest
I’m a medical grad turned self taught software engineer . I work with python and the javascript ecosystem . I’m also web application security researcher finding bug on hackerone.
Over 35 years here. I use IDEs for the heavy lifting (RubyMine nowadays), but simple/quick edits are more easily done with vi(m). Muscle memory is a thing not to be discounted.
Are you saying that is overrated? just because it appropiated common sense, made it rigid, replaced common words with "cool" terms and made a ecosystem of courses, certifications, levels, etc. Now, you could have the experience and good common sense, but are you a crapbelt 90dan?, do you know all the fabricated "technical" jargon? have you paid the courses and certificates?.
Don't do useless things, don't waste time. SCRUM invented that!
EU 🇪🇺 | Art, Tech & Good Vibrations 🤳 | Founder of ᴛᴏᴍᴏʀʀᴏᴡ 🌞 hellotomorrow.agency • Just started working on a new endeavour 👉 usepoe.app • Follow me on Twitter!
Location
Brussels, Belgium
Work
UX Engineer, Product Manager, sometimes Designer at Self
I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
I would say React in general. It has become synonymous with front-end. It has a steep learning curve and its own terminology/patterns that are foreign to those that do not use it but that are proficient in web development. Other frameworks/libraries seem to do all of the same things, have similar performance, and are more beginner-friendly. I'm not sure why I would reach for React other than for an existing project or its popularity.
I would also say some new features added to React are also overrated. They solve problems that only exist because React created those problems. I'm not against the library being improved and simplifying the use of it, but the hype over some things seems unwarranted. There seemed to be a lot of friction caused by classes (and their verbosity) vs. functional components, prop-drilling, render props, and higher-order components. The recent updates add to the developer experience but add another React-specific concept to learn. The most recent example I can think of is "hooks" or as I like to call them "function calls." I'm definitely oversimplifying what they do and it has made React code much simpler, but c'mon, you are just calling a function to do something. What was all the hype about?
It took me 3 weeks to become as proficient in React as a year in Angular. Steep learning curve is not really accurate. Unless you basically never tried it for more than a few minutes. The only reason it seems overrated is because it's so widely used, because it's so good. Does it seem simple? Yeah, that's a good thing. When something so simple can do so much..
I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
I was thinking more along the lines of Vue, Svelte, and libraries of that nature being more beginner-friendly alternatives that are similar to React.
I think the learning curve for React not only comes from the concepts I mentioned above but the ecosystem as well. The library is barebones, API is minimal, and there are no accepted conventions. That could be positive or negative for some people. For me, it is negative. Getting started and learning to write components is not too bad, I would agree with you there. But the trouble comes when someone may just want to build an app to solve a problem. They have to worry about structuring an app, adding routing, styling components, forms, etc. while keeping everything manageable. It adds more learning, more configuration, and more troubleshooting on top of learning the library.
It's just Javascript. Svelte is a bunch of its own specific conventions. React is not hard to learn. Unless you only barely tried once. It's just so easy
I’m a medical grad turned self taught software engineer . I work with python and the javascript ecosystem . I’m also web application security researcher finding bug on hackerone.
It never was strange to me and I've embarked on the SPA bandwaggon with Meteor. But I do agree that it created new whole concepts different from the traditional web's. The simplicity of it (just a view library) is why I go with it instead of Angular. I've got a set of libraries I usually use with React like axios, rematch, styled-components. I think about React as a whole new platform to build interface upon, not something to manipulate the dom like jQuery does
I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
Riot looks awesome, I like their philosophy of keeping things simple and close to web standards.
I have been working with Stencil recently which has a similar mission. Stencil uses TypeScript, JSX, and a minimal API and compiles to web components. I'm liking it so far but I'll keep Riot in mind.
Giving a short but interesting exercise to be done on the person's time and to be explained in front of your interviewer. It's a great opportunity to work in normal conditions (at home or anywhere you feel comfortable) and to explain why and how you did things.
But if I do have a multi-page site, using a static site generator would help prevent me from having to make the same changes multiple times (i.e., in the header or footer, or in sections that require the same sets of class names).
I really just like not having to copy/paste large portions of markup. I can be clumsy.
There are other ways of ensuring you don't need to edit muliple header/footer files (include in PHP for example). But like I said, I believe SSG's certainly have a place, but they're overhyped.
Seriously, if the code works and you can read who cares how many spaces or tabs it has? Who cares if there are hash rockets? If the compilers don't care, we shouldn't either
Before I totally agree, I do have to ask if this would cause a lot of extra white space changes to appear in shared code. That would be my only issue.
Other than that, yeah, I don't care for arguing over personal white space preferences, so long as there's some kind of agreement or compromise within a team.
I have strong opinions on syntax because it helps me manipulate code faster. I like typing Tab to indent but I like it that all my whitespace is space so I can move the cursor inside (something I rarely do, btw). I like semicolons after my line because I've started with C and it's a habit now.
I won't argue about syntax opinions and I'm more than happy to follow the one the team decided. But my own is just so comfortable.
I write from time to time.
Views expressed are my own and may not represent the opinions of any entity with which I have been, am now, or will be affiliated.
Strongly disagree. (15+ years small-a agile experience here.)
The last shop I was with moved to pair programming after three different pilot groups showed 20-30% improvement in raw productivity and 80-90% reduction of bugs making it to production compared to solo ninjitsu.
It takes a different, less ego-driven way of thinking, but that's one of the main arguments for it. The shop I'm with now doesn't do that simply because a politically-protected "dev" refuses to do that, and we're years behind schedule. Not pairing isn't the only reason for that, but it's a major contributor.
Popular thinking (in non IT sector) that developers just sit 8h a day in front of their computers, drink coffee, chit-chat with coworkers and play games...
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
Clearly not all of us like coffee, and lets face it, we have real trouble limiting ourselves to 8 hrs. Can't chat as much as I would like as I work from home.
I totally agree. I just hate when someone says this. Had couple situations where someone called me in work time and ask if I can do something for him because he is at work 🙄
Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
Ie Red Team vs Blue Team where people preach inclusiity while actively excluding anybody who doesn't strictly align with their unique brand of political identity.
I'm here to build the future, with anybody capable -- or at least willing -- to contribute. Not play the 'pander to special interest flavor of the month' game.
EU 🇪🇺 | Art, Tech & Good Vibrations 🤳 | Founder of ᴛᴏᴍᴏʀʀᴏᴡ 🌞 hellotomorrow.agency • Just started working on a new endeavour 👉 usepoe.app • Follow me on Twitter!
Location
Brussels, Belgium
Work
UX Engineer, Product Manager, sometimes Designer at Self
Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
Sili Valley is toxic, not least in the founder-fetish mentality it celebrates. The farther away from it you get, geographically and culturally, the better developer you will become.
Sturgeon's Law is a thing. 90% of everything is crap. Your primary responsibility as a dev is determining what 10% is not, and leveraging the hell out of it.
Electron, while everyone is trying hard to make the web as fast as native, Electron took a revolutionary idea, let's make the native as slow as the web. Instead of making things simple removing unnecesary layers, let's add more. What I want to see is a desktop "app" (I'm using the term with all the disdain I possess) that generates an React or Angular webapps or maybe other Electron "apps", that would be glorious. Just 1 step closer to the dream of OS written entirely in JS, Freddy Krueger would be proud.
I've long called Scrum the Project Manager's Full Employment Act 1996-2019.
Every single Scrum project that I have directly observed has failed to meet at least half of the agreed-to objectives and/or deliverables by the time the plug was pulled. That drops to <10% for the non-Scrum agile projects I've observed or participated in over the last 15 years.
Agile, yes; Scrum, not without inexhaustible resources (including schedule and customer patience).
JavaScript frameworks. They tend to make some things easier and take care of a lot of hassles for us. It makes some think frameworks are needed to make powerful apps and become a better developer.
But I'm seeing more and more instances of things done in HTML, CSS and plain JavaScript that look so complex that it feels impossible to believe at first glance, that they were made without any framework or library.
I believe frameworks are important to learn and understand, but they negatively affect our growth when used as a crutch.
Is there something that only Electron made possible with VS Code or GitKraken?, the fact that they were made with web tech somehow better?, is all that extra overhead necessary? I haven't used either of those (strict no Electron rule in my machines) but after a quick look there is nothing there that couldn't be done without all the extra cost of a platform on top of a platform on top of another platform, seems to me that they are good despite Electron not because of it.
That's a dev advantage, when I develope something I think in what gives value to the user, there is a lot of crossplatform SW around. If you want to keep the dev process simple, well do a webapp and give me the tools that a browser gives, you want to make a desk program then give me the performance, don't give me the worst of both worlds, instead of Electro you might be able to separate server an client and make it more flexible and use the browser control. Of course is just my priorities, I don't think that Electron shouldn't exist or their users are wrong, it's my view, I also think SCRUM is overrated and maybe has been useful to others. There is no such thing overrated in absolute terms. To me an Electron app is an unnecesary waste of my limited resources. So if an app uses it is a deal breaker.
Engineering Manager in OLX Group.
AWS Certified Solutions Architect, fascinated with a serverless cloud architecture. JavaScript Trainer, enthusiast and coding geek. Recently in love with Rust lang.
"Advanced" web development in general - roughly 75% of use cases can be done equally good with simpler solutions
Blockchain, AI and other buzzwords - everyone claims to be using those, in fact just few companies on the entire world are able to do something productive with those.
I believe that's called Hype-Driven Development; it should be a firing offence. Pilot programs working on small, identifiable features or utilities are gold.
Humanist living the Colorado life, w/ a modicum of scripting experience. My background is across multiple industries (mostly contract work). Emotional intelligence > Artificial Intelligence
I kinda get saying other methodologies are overrated but I kinda thought Lean was, you know, lean. What's not to like about building a minimum viable product and iterating on it?
Linux was a hobby project which seems like a lean start. Software isn't physical so analogies about architecture often don't fit. I agree I wouldn't build life support system software with lean. For things as diverse as global financial software, government digital services and startup consumer software, I have seen that starting by building a minimal viable product seems to work better than upfront design in my experience. I would love to read about your experiences of where and why it doesn't work as there are no silver bullets.
I’m a medical grad turned self taught software engineer . I work with python and the javascript ecosystem . I’m also web application security researcher finding bug on hackerone.
Gentoo Linux and VIM worshiper, C developer, network protocol dissector implementer,socket/network programmer, recently entered the embedded world, hater of buzzwords and made up titles
English lad currently a C#/Java/VueJs/JavaScript/TypeScript engineer.
Extra dribbling can be found at https://codeheir.com
Portfolio found at https://lukegarrigan.com
dev/IoT advocate.
my neurotransmitters enjoy: foodie, penguins, and esoterica (the arts, oddities, antiques).
my demons have funny names: AuDHD/MDD/GAD/cPTSD
React
Micro-services
Apple products
Microservices, with my last breath I spit at thee.
The basic architectural principle behind them is similar to Unix apps, where you have small applications each with a narrow scope. You use plumbing to pull them together into complete systems. The idea is to break things into independent subsystems that are weakly coupled. In theory.
In theory if you observe the idea of having a narrow and specific scope while decoupling from the domain they have application. Certainly the play a big part in distributed systems.
Where they come undone is when they are tied tightly to the domain, sharing the data model. If this happens they either end up sharing the persistence mechanism, aka the database, and thus having a central point of failure, or having integration and query nightmares when you try to pull data together from multiple Microservices into a single coherent view.
As with many other areas they are adopted and implemented as some kind of silver bullet, but without a skeptical analytical approach to their implementation can turn into the classic Big Ball of Mud, where Microservice is piled on top of Microservice with little or no concern about clear architectural separation of concerns.
In my experience they become tightly coupled to narrow use cases and lead to an unmanageable explosion of code and nightmare of latency. Perhaps some companies have the engineering discipline to implement them right, but too often this isn't the case.
I may add that use of microservices makes deployment and maintenance much more complicated than it needs to be. And makes local deployment for testing/debugging at least very inconvenient (usually just impractical, often even impossible).
Possibly I know better solution than microservices, I've described it in my blog here, at dev.to recently.
I read your article. Looks good, if only because I have adopted something very similar. With Gravity there is dynamic runtime configuration which can create new data structures and related API. Business rules, views, filters and integrations are all defined at runtime through the API. It is a clustered system so that all the services run on each node, so regardless of the API called it is capable of servicing it without doing another hop. It uses JMS queues to manage workload across the cluster. Because each node of the cluster is identical you will never get resource bound on a specific service because any node can do anything. There are three clusters involved, the API, JMS and Persistence.
So true though. Most attempts for Microservices with no real value addition ends up with distributed monolith when the attempt goes ill planned. Especially small teams, attempting the route for the hype.
The real value of micro services is at scale.
And the real danger of micro services is deploying them before it's necessary
Yes true.
Curious why React? Are you saying Vue or Angular are better? FWIW I don't use React myself.
What's underrated is using none of them.
This.
It's easy for a beginner to assume that every company out there is using a front-end framework.
I'm still seeing lots of both greenfield and brownfield projects using vanilla JavaScript with a .NET, Java or PHP backend.
Building everything as a SPA
100% this!
Yeah, I found myself on that bandwagon for a short time when Meteor came out. Very fun to work with, and the SPA idea is very attractive. But it adds a lot of complexity and some other issues that normally don't happen on server-rendered websites, and there are little pieces of different projects that can be made interactive without going full-blown SPA.
That gotta be the iPhone.
MacOS, WSL, npm, react, BEM, OOCSS, Wordpress, Vanity points, Sublime Text, OhMyZsh, NerdTree, Flat Whites, Imposter Syndrome, seafood, any product variant that starts with the word "Gaming", "modern" PHP frameworks, one-liners, aliases, influencers, "devrel", 10x developers, BMWs, italicised code comments, dark mode, the United States, conference swag, people who humblebrag, millisecond optimisations.
draws breath
WSL: yeah, I'd rather just use either Windows or Linux (and I do: Windows on company-owned laptop, Linux on my personal laptop).
OOCSS? I don't even wanna know...
Is WordPress overrated among devs, or do you mean vs. other blogging platforms or website builders? It's fairly easy to set up quickly, which seems to be why it has so much all-around support. But its DB storage is definitely bloated, and most themes I've used are loaded with gimmicks rather than being focused on performance.
So no, I don't care for it. Was just wondering what you meant.
Dark mode is a personal preference for me, but yeah, each person and work environment is different. "To each his own."
Wordpress is ubiquitous but it's not very well made. It takes a lot of ideas from old-style PHP and just runs with them. People like Gutenberg but it just encourages storing chunks of non-semantic, non-transformable HTML in the database. People bolt things on and call it a CMS, but it's really not designed to be one.
I was with you till you said seafood... 🤨
:P
Very true. "draws breath" ha.. ha.. :)
Vim.
How do you know if a developer uses Vim? Don't worry, he'll tell you.
IMHO, vim is worth the hype. And long time vimmers are fairly rare
Found the dev that uses Vim.
It’s not
Thats just like, your opinion.
Over 35 years here. I use IDEs for the heavy lifting (RubyMine nowadays), but simple/quick edits are more easily done with vi(m). Muscle memory is a thing not to be discounted.
react. I just need a button, not a button factory.
Yeah... but what if?
apply for VC funding...
Utilization, i.e. how busy people are. And working early/late as a status symbol.
Elon joined the chat
*reads your message
Elon left the chat
Scrum
Are you saying that is overrated? just because it appropiated common sense, made it rigid, replaced common words with "cool" terms and made a ecosystem of courses, certifications, levels, etc. Now, you could have the experience and good common sense, but are you a crapbelt 90dan?, do you know all the fabricated "technical" jargon? have you paid the courses and certificates?.
Don't do useless things, don't waste time. SCRUM invented that!
❤️
Javascript 🙄
I would say React in general. It has become synonymous with front-end. It has a steep learning curve and its own terminology/patterns that are foreign to those that do not use it but that are proficient in web development. Other frameworks/libraries seem to do all of the same things, have similar performance, and are more beginner-friendly. I'm not sure why I would reach for React other than for an existing project or its popularity.
I would also say some new features added to React are also overrated. They solve problems that only exist because React created those problems. I'm not against the library being improved and simplifying the use of it, but the hype over some things seems unwarranted. There seemed to be a lot of friction caused by classes (and their verbosity) vs. functional components, prop-drilling, render props, and higher-order components. The recent updates add to the developer experience but add another React-specific concept to learn. The most recent example I can think of is "hooks" or as I like to call them "function calls." I'm definitely oversimplifying what they do and it has made React code much simpler, but c'mon, you are just calling a function to do something. What was all the hype about?
It took me 3 weeks to become as proficient in React as a year in Angular. Steep learning curve is not really accurate. Unless you basically never tried it for more than a few minutes. The only reason it seems overrated is because it's so widely used, because it's so good. Does it seem simple? Yeah, that's a good thing. When something so simple can do so much..
I was thinking more along the lines of Vue, Svelte, and libraries of that nature being more beginner-friendly alternatives that are similar to React.
I think the learning curve for React not only comes from the concepts I mentioned above but the ecosystem as well. The library is barebones, API is minimal, and there are no accepted conventions. That could be positive or negative for some people. For me, it is negative. Getting started and learning to write components is not too bad, I would agree with you there. But the trouble comes when someone may just want to build an app to solve a problem. They have to worry about structuring an app, adding routing, styling components, forms, etc. while keeping everything manageable. It adds more learning, more configuration, and more troubleshooting on top of learning the library.
It's just Javascript. Svelte is a bunch of its own specific conventions. React is not hard to learn. Unless you only barely tried once. It's just so easy
Exactly , Angula is way way harder than react
It never was strange to me and I've embarked on the SPA bandwaggon with Meteor. But I do agree that it created new whole concepts different from the traditional web's. The simplicity of it (just a view library) is why I go with it instead of Angular. I've got a set of libraries I usually use with React like
axios,rematch,styled-components. I think about React as a whole new platform to build interface upon, not something to manipulate the dom like jQuery doesTry Riot JS - it's awesome
Riot looks awesome, I like their philosophy of keeping things simple and close to web standards.
I have been working with Stencil recently which has a similar mission. Stencil uses TypeScript, JSX, and a minimal API and compiles to web components. I'm liking it so far but I'll keep Riot in mind.
The chain of blocks
Whiteboarding
What alternative would you propose? Genuine question. I hate whiteboarding as well.
Giving a short but interesting exercise to be done on the person's time and to be explained in front of your interviewer. It's a great opportunity to work in normal conditions (at home or anywhere you feel comfortable) and to explain why and how you did things.
Project based problems are the best. Give them something small that showcases problems in the project.
Developer's opinions
Haha totally!
Static Site Generators
Hyped, but quite useful(at least for me)!
Useful in certain circumstances to be sure! But you don't always need a SSG... sometimes vanilla HTML/CSS will suffice for a simple site!
But if I do have a multi-page site, using a static site generator would help prevent me from having to make the same changes multiple times (i.e., in the header or footer, or in sections that require the same sets of class names).
I really just like not having to copy/paste large portions of markup. I can be clumsy.
There are other ways of ensuring you don't need to edit muliple header/footer files (
includein PHP for example). But like I said, I believe SSG's certainly have a place, but they're overhyped.Syntax opinions.
Seriously, if the code works and you can read who cares how many spaces or tabs it has? Who cares if there are hash rockets? If the compilers don't care, we shouldn't either
Before I totally agree, I do have to ask if this would cause a lot of extra white space changes to appear in shared code. That would be my only issue.
Other than that, yeah, I don't care for arguing over personal white space preferences, so long as there's some kind of agreement or compromise within a team.
I love code formatters. I like writing my js without semicolons, so what? Its all made to look identical as soon as I commit!
As long as the formatter keeps the logic, and is readable. I couldnt care less.
I have strong opinions on syntax because it helps me manipulate code faster. I like typing Tab to indent but I like it that all my whitespace is space so I can move the cursor inside (something I rarely do, btw). I like semicolons after my line because I've started with C and it's a habit now.
I won't argue about syntax opinions and I'm more than happy to follow the one the team decided. But my own is just so comfortable.
It's not exactly a opinion though - it's a fact that in python no semicolons and brackets means less typing needed :P
pair programming
Strongly disagree. (15+ years small-a agile experience here.)
The last shop I was with moved to pair programming after three different pilot groups showed 20-30% improvement in raw productivity and 80-90% reduction of bugs making it to production compared to solo ninjitsu.
It takes a different, less ego-driven way of thinking, but that's one of the main arguments for it. The shop I'm with now doesn't do that simply because a politically-protected "dev" refuses to do that, and we're years behind schedule. Not pairing isn't the only reason for that, but it's a major contributor.
I don't know where did you take those numbers from, but ❤️ for the last paragraph.
Reads like internal data.
This code snippet:
Popular thinking (in non IT sector) that developers just sit 8h a day in front of their computers, drink coffee, chit-chat with coworkers and play games...
Clearly not all of us like coffee, and lets face it, we have real trouble limiting ourselves to 8 hrs. Can't chat as much as I would like as I work from home.
I totally agree. I just hate when someone says this. Had couple situations where someone called me in work time and ask if I can do something for him because he is at work 🙄
Politics in Tech
Ie Red Team vs Blue Team where people preach inclusiity while actively excluding anybody who doesn't strictly align with their unique brand of political identity.
I'm here to build the future, with anybody capable -- or at least willing -- to contribute. Not play the 'pander to special interest flavor of the month' game.
Curious to know where you found politicised environments?
Tech Twitter and SF mostly
Not sure if it's just an outside-in perspective but Silicon Valley seems like a cesspool of toxic personalities.
DevTo is cool tho. It seems to be one of the few online dev communities that's healthy, positive, supportive, encouraging.
Sili Valley is toxic, not least in the founder-fetish mentality it celebrates. The farther away from it you get, geographically and culturally, the better developer you will become.
Suscribe to the C topic
0 post this month.
:'(
Why the water cooler hashtag😅
Math in general coding is overrated
Code golfing is overrated
Writing super short code like... uh, let me Wikipedia that
University
Need I say more😅
Those are the ones I could think of off the top of my head
Followup article: "what is underrated😆"
University degrees.
Everything.
Sturgeon's Law is a thing. 90% of everything is crap. Your primary responsibility as a dev is determining what 10% is not, and leveraging the hell out of it.
Maybe half of everything. But the half you've heard of.
Electron, while everyone is trying hard to make the web as fast as native, Electron took a revolutionary idea, let's make the native as slow as the web. Instead of making things simple removing unnecesary layers, let's add more. What I want to see is a desktop "app" (I'm using the term with all the disdain I possess) that generates an React or Angular webapps or maybe other Electron "apps", that would be glorious. Just 1 step closer to the dream of OS written entirely in JS, Freddy Krueger would be proud.
VS Code is built on electron...
That is my only example of a good electron app.
I've long called Scrum the Project Manager's Full Employment Act 1996-2019.
Every single Scrum project that I have directly observed has failed to meet at least half of the agreed-to objectives and/or deliverables by the time the plug was pulled. That drops to <10% for the non-Scrum agile projects I've observed or participated in over the last 15 years.
Agile, yes; Scrum, not without inexhaustible resources (including schedule and customer patience).
JavaScript frameworks. They tend to make some things easier and take care of a lot of hassles for us. It makes some think frameworks are needed to make powerful apps and become a better developer.
But I'm seeing more and more instances of things done in HTML, CSS and plain JavaScript that look so complex that it feels impossible to believe at first glance, that they were made without any framework or library.
I believe frameworks are important to learn and understand, but they negatively affect our growth when used as a crutch.
Is there something that only Electron made possible with VS Code or GitKraken?, the fact that they were made with web tech somehow better?, is all that extra overhead necessary? I haven't used either of those (strict no Electron rule in my machines) but after a quick look there is nothing there that couldn't be done without all the extra cost of a platform on top of a platform on top of another platform, seems to me that they are good despite Electron not because of it.
Working from a coffee shop like a lot of blogs and discussions suggest.
If it's scraping data to save in a JSON file or creating a UI, cool. Anything else that might even involve connecting to a db, nope nope nope.
That's a dev advantage, when I develope something I think in what gives value to the user, there is a lot of crossplatform SW around. If you want to keep the dev process simple, well do a webapp and give me the tools that a browser gives, you want to make a desk program then give me the performance, don't give me the worst of both worlds, instead of Electro you might be able to separate server an client and make it more flexible and use the browser control. Of course is just my priorities, I don't think that Electron shouldn't exist or their users are wrong, it's my view, I also think SCRUM is overrated and maybe has been useful to others. There is no such thing overrated in absolute terms. To me an Electron app is an unnecesary waste of my limited resources. So if an app uses it is a deal breaker.
Redux and everything built around that.
"Advanced" web development in general - roughly 75% of use cases can be done equally good with simpler solutions
Blockchain, AI and other buzzwords - everyone claims to be using those, in fact just few companies on the entire world are able to do something productive with those.
Switching to the newest tech with little thought. "The Grass Is Greener..."
I believe that's called Hype-Driven Development; it should be a firing offence. Pilot programs working on small, identifiable features or utilities are gold.
React, Flutter, and in general forced code sharing between platforms.
AI
buT We HaVE MAChiNe LeArNiNg Ai!...
React
Typescript
.....perhaps the new iPhones
Relationships between humans, especially opposite gender relationship are sooo overrated.
Lean.
I kinda get saying other methodologies are overrated but I kinda thought Lean was, you know, lean. What's not to like about building a minimum viable product and iterating on it?
Well, would you build a skyscraper by first building a bungalow and then adding more floors on top?
Linux was a hobby project which seems like a lean start. Software isn't physical so analogies about architecture often don't fit. I agree I wouldn't build life support system software with lean. For things as diverse as global financial software, government digital services and startup consumer software, I have seen that starting by building a minimal viable product seems to work better than upfront design in my experience. I would love to read about your experiences of where and why it doesn't work as there are no silver bullets.
Agile principles
Backend engineering
Richard stallman
+100 for Stallman. #cancelstallman has been trending, and it's about time.
Agile works, as long as you avoid Scrum like the plague that it is.
Backend engineering, as a special case of "software engineering", is an oxymoron. Don't give oxy to morons.
Companies with this description: "Disrupting Enter any buzz word (Cloud Computing, AI, ML, Big Data, BlockChain ...)"
Everything that doesn't withstand the test of time. Simple as that.
Ligatures 😬😬
Those screenshots tho 👌
Dont forget to add Synthwave 84
This post. ;)
Ben Halpern's questions ( ͡° ͜ʖ ͡°)
(ง ͠° ͟ل͜ ͡°)ง
I've been told "everything is awesome". Thus, nothing can be overrated.
Chick-fil-a. Sorry.
Meetings that last over 10 minutes.
Kotlin
React
Dark Theme for everything.
I feel like it depends on the amount of natural light you have and your own eye strains.
I live in Haiti and I've got a lot of natural light. It feels like the planet Riddick was on (The second movie). Dark is more easy for me.
Silicon Valley.
Coffee!
AI
Gatsby JS
Fullstack developers competency
Microservices
Agile
Writing articles
JavaScript Frameworks.
Like, goddamit..