markdown guide
  1. TDD is a meme and you shouldn't be writing tests before you even know what your modules will look like.

  2. Writing code is an art form. It takes intuition and freeform thought to structure things.

  1. TDD is the only way to create code that is maintainable and extensible. Unless of course, what you are making is utterly simple.

  2. Writing code is a science, not an art. The problem is that humans have spent less than 60 years doing code and we do not have the hang of it completely that is why point 1.


_ is the only way to create code that is maintainable and extensible

That's what they said about COBOL.

And when some wise guys at Cambridge said, hey we've invented a replacement to COBOL called "CPL" everyone said "We don't need yet another programming language!"

(CPL -> BCPL -> C -> C++/ObjectiveC -> Java/C#/Swift/Kotlin/Go/Scala/...)

So, I've added another of my unpopular opinions:

We will always need Yet Another Programming Language

Because as Adrián said, we're pretty new at this, and so we need better tools. We're still in the software stone age.

Thank you for the quotation. I have the same opinion. We don't need too many more programming languages and frameworks.

With the programming languages happen the same that with the mobile phones. The unique reason new ones are needed is to make the old ones obsoletes and try to take control of the market.

Can someone really tell me why was Ruby needed in the moment of its creation? What does it provide that could not be added to existing languages?

The principle of "Do not repeat yourself" that science respect is not not followed most of the time.

It seems that the theory behind sofware development doesn't matter anymore and the they're is a global hype on languages like Javascript that is dangerous becoming the ground stones of apps without being so mature as language or some optimal for execution.

It is like if some new tech allows to recycle the garbage in a new material javascriptolite and they're is a boom in sell of cars with "futuristic" look, low weight and a hammer toolkit to shape it yourself to the shape you like.

Of course many skilled people will make from Javascriptolite a new market. But some day people will start to read again physics and mechanics.

Or would somebody build an space ship from that material?

  1. I tend to agree that TDD is a bit excessive, but I strongly believe in a BDD approach which is very common in Domain-Driven Design. Writing the failing test cases that describe how what use cases, policies and rules a system should have is much more likely to be known at the start of a project than if "computeXYCoordinates()" returns false :)

  2. Writing code is a mixture of both!

It's science!

  • Computer "SCIENCE" is theory. The way that mathematics, physics and information work together to "determine how many users this application will be able support under peak hours" is a bit of physics, math, and probability all in one!

A very common feature in science is that it's very hard (and sometimes impossible) to prove that something is correct, so we often deem things correct enough if we can't prove it to be false.

That's unit testing :)

Computer "programming/coding" is the practical application of such theory. It's also what leans more in the direction of....


  • There are 100s of ways of writing code to perform the same observable behaviour. It takes skill, practice, patience and empathy to create code that is timeless, well-designed and readable for future developers.

Writing code is hardly science, any more than writing fiction is. We are craftsmen and -women, not scientists.

The word Craftsmen has nothing to do with gender it does mean -women aswell.
Craftswomen is not even a word in English.

That's an unfortunate accident of the English language. It's not a problem elsewhere (mann/frau, uomo/donna, etc). Ask a computer and it would say "woman contains man so the former is more generic".

I think this isn't a fight we should be focusing on, there are much bigger battles to fight for gender equality, this kind of petty and surgical word picking just brings bad name to the whole issue, which so many feminists fail to understand.


😂 In a fit of frustration on Friday afternoon bc I couldn't get specs to cooperate I put this message in slack. I'm kidding of course, mostly....

  1. TDD has its place, in some scenarios it's the only sensible option, but its benefits in general are massively overstated.

  2. Writing code is more like artisanship. I feel I've got more in common with someone who builds bespoke wooden furniture than a painter.

  1. ...

I think the truth exists somewhere in the middle. I did a coding dojo with a brilliant manager a few years back on TDD, and learned a lot about the value of unit tests.

The first advantage is that it gives you a usable API (API is UX). It's all too easy to get tunnel vision and write an unusable API because you've never attempted to use it. The "doesn't compile" step in TDD makes sure that you are trying to use the thing before making the thing.

The other advantage is that it prevents you from solving problems that don't exist. The specific example we had was roman numerals. At the start of the session I felt a bit of dread: roman numerals are, superficially, pretty hard to parse. Working through "I" to "III" to "MCVIII" resulted in a complete solution that was far simpler than the one I conjured up before we started coding.

But, you'd never get anything done if you followed TDD strictly.

I think the middle ground is writing your code while visualizing the test. This ensures that you are writing units (which are easier to use and obviously easier to unit test).


Couldn't agree more. TDD is workable when you're well staffed and have some discretion over deadlines. Otherwise it's an incredibly difficult sell from a business value standpoint, unfortunately. Especially if you're in an organization where certain delivery timelines are expected regularly


Most of the cost of software is after the initial build. TDD helps keep it decoupled so it's easier and cheaper to maintain in the long term. TDD software probably has better TCO.


Write the code. Does it work? Write a test to prove it. Write more tests as you think of ways to break it.

Found a bug? Fix it. Write a test to prove it was fixed.


I don't think you have to let software/coding consume your life to be good at it. It's ok if you don't code outside of work. It's ok to have a life outside of this.


Caveat: you need to make peace with the fact that you will never be as good or experienced as the guy that codes in his free time for fun.


I totally disagree being a well rounded human with other hobbies and strong soft skills is better than a dude who codes 24/7 especially when that dude gets burnt out.

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Objectively speaking the captain autismo who codes 24/7 will always write code better than someone who only does it 9 to 5. We're not really arguing which is best for the human.

No the half asleep burned out Red Bull fueled constant coder is going to write sloppy code and insist his coworkers are just too dumb to read it.

@sergio - hey, that "captain autismo" comment seems pretty inappropriate. You might want to reconsider that.


Yes, because the dude that codes 24/7 in 3 years might be going into another field altogether, while a somebody that takes it slower might be in the game longer.

In my experience, more than 10 years, that is wishful thinking.

The people who code 24/7 on personal or open source things love doing this to a point of near obsession and I know of some who have been living that way for more than 15 years (yeah, meet them when we were teenagers and they lived glued to computer science books) and at that point you just have to accept that you will never be nearly as good as them and then be glad to be able to learn from them.


You can write good quality code in PHP :)


I love PHP. It's the thing I've spent the most time with so it's what I'm most comfortable with.

I'm starting to learn React and playing around with Python a little bit at work, but PHP is what I've always used and always want to come back to.


Exactly, that was my point. you can write clean code in any language ;)

Of course you can, do not let anyone tell you otherwise. Most of the time when people bash PHP it's because the scenarios on where it is the ideal language to use are very narrow.

Or because they haven't used it recently. PHP 7 really turned my opinion around on it. As did Laravel


Does it count if I use a PHP framework? I mainly use Laravel :D


Really, PHP as a language is so restricting that there are a lot of things you simply cannot and should not code in it. Additionally the whole design for the typical use of the language - a collection scripts that get evaluated from start to end for every web request, triggered by access through a web server - is so bad that it has lead to countless incredibly misguided design decisions and massive numbers of hacks and other issues.

As an example, there's WordPress having all the modules deployed under the public folder and then access to them gets you direct "access" to the code, so all you need to find is one ignorant developer's one bad module and scan the world for all installations of it to hack a big pile of websites. This is the legacy PHP has given us.

Add to that the fact that the language has countless really bad design choices, that simply waste your brain power in useless things - does the function have underscores, does it take haystack before needle, and other such questions constantly waste your time when they could be standardized, and the language community simply refuses to fix their countless past mistakes keeping "backwards compatibility" as some sort of gold standard that must never be sacrificed.

In short: Yes, you can produce code that is better than WordPress in PHP, but you can never be a good programmer while using PHP - you waste too much of your time on things other than producing good code.

Everyone really should read this if they haven't eev.ee/blog/2012/04/09/php-a-fract...


In order to help junior devs grow you have to let them struggle. You can't give them all the answers, they have to spend time in the trenches finding the answers themselves with a little guidance.


Something I do when mentoring a junior developer is to tell them that if they get stuck on something, they should try and solve it by themselves for fifteen minutes (adjust the duration depending on the situation) before they ask for help. But if they’re still stuck on the same thing after these fifteen minutes, they have to ask for help.

I found it has many benefits. First, it makes it clear that it’s OK to ask for help. Second, it sets a balance between them interrupted you too often (which is frustrating to you) and not making much progress (which is frustrating to them, which is worse). Often, when they finally come for help, even though they’ll fell that they were just stuck for 15 minutes, in reality they will have come close to the solution, and you can show them how they almost solved it.


I often recognized that Juniors “just” lack of
confidence, not of knowledge.

They know the answer but are not sure if it’s the right one.

One step away from being a Junior is to just do it. Better ask for forgiveness than for permission.


I've been in the field of coding in general for around 4 years. Even though I know I have worked really hard, I've never done anything professional and I fear I will do horrible with an actual job.

Never done anything besides experimenting and personal projects. And I constantly feel like a Junior dev that has no clue what they're doing.

Especially since I've been focusing in the security aspects of things, I feel like I have barely touched the surface of things.

First off, kudos to you for focusing on the security aspects of things! That puts you ahead of a lot of others.

I have been coding professionally for 6 years, and let me tell you, I have plenty of days still where I have no clue what I am doing!

The tech world moves so fast and evolves so quickly that even those who have been in the field for years have to constantly learn new things. Because we are all constantly learning, we are all juniors or newbies at one thing or another. The key is you have to become OK with being uncomfortable and know that its just part of being a dev.

I also bet because you have done lots of experimenting and personal projects you are probably pretty self sufficient and scrappy which are both GREAT characteristics to have as a dev. Don't be intimidated by the word "professional", give it a shot and apply for a job! If you want some more motivation read this post my coworker wrote.

Thanks for the wonderful post. You write great articles BTW.

There are a lot of talented people on here.

It's nice seeing everyone trying to get together.


"Better ask for forgiveness than for permission.", nicely put love it!


Maybe too unpopular but here it is:

Apple's Macs are way overrated for software development, not worth the money (at least for me) for the hardware specs of their computers, I feel like I only have to use one because they force developers to compile iOS apps in a Mac. Some people say they like its terminal because its better, and they are correct, out of the box its terminal is very good, but you could setup correctly your terminal in Windows or Linux to run as the Mac one, saving you hundreds of dollars and having much better hardware.


I don't understand how Apple could've thought it a good idea to remove the escape key and without at least one USB-A port.

I've used Macs for 10 years because I can't stand Windows, and I need some applications that aren't available for Linux. Pretty sure my next mac will be a hackintosh.


I like using them because I find them at a sweet spot between the freedom of Linux and the maintenance a Window need. But I can totally see your point.


This probably counts as another unpopular opinion, but Windows (10 with WSL and an X Server installed) isn't that bad.


Exactly this, the reason I am using Mac right now, and boy it feels good!


I've got a 2015 MacBook at home that I love developing with. But I wouldn't want to buy a current model, not with all the keyboard issues and lack of anything-but-USB-C ports. Year after year, Apple feels more like a luxury/lifestyle brand than a technology company.


Kudos to the ternary operator! I greatly appreciate your compactness from time to time! And don’t let those bullies tell you you’re hard to read. You are fine just the way you are. W?t:f.


Key phrase: time-to-time

Don't mind ternary operators for simple cases but once someone starts putting multiple function calls in each part of the operator, it makes it difficult to debug.


Very much this. If you have more than one ternary operation in a statement, you need to not use any.


Hell yeah! I'm with you, nothing like a set of ternary operators when you're iterating through an bunch of variables. They also make intutive sense to me, even more so than IF/ELSE even - I see the symbols and I think

"this thing happened, yea ? ok, do this : no - ok, do this"


The main argument against it seems to be "junior devs won't understand it". I think the answer to that is that they should learn the language.


Yeah sometimes a deep dive into the language will clear up most problems you have as a Jr.


Not sure if unpopular but:

The term "Impostor Syndrome" is way too overused.

What people usually feel is not I.S., but they are simply realizing how little they know.
Which is totally fine and also important.
You can be a non-master in a field and still get paid to do it.
It doesn't mean your boss/followers/mom/dad thinks you're much better than you actually are.

I just hope folks don't take I.S. as excuse to think they are good at something while they're not.


I agree in some level with this sentiment. I can't speak for others, but for myself I often struggle with recognizing whether I'm suffering from Impostor Syndrome or if I'm just recognizing how little I actually know about something the more I learn about it. The more I learn, the more I realize how little I actually know and how much more there is to learn. I suppose this is the Denning-Kruger effect in action!


Ouch no responses, you hit a nerve :D


Not sure, maybe the post simply has too many replies. Or maybe it‘s not an unpopular opinion, therefore it‘s not a good reply 😬


A person thinking they have impostor syndrome to feel good about themselves by definition can't have impostor syndrome 😅

It is a debilitating trench from which the climb out is very difficult. All the people I know that I consider to truly have impostor syndrome are excellent at what they do and what they understand, their brains are just not able to accept their victories.


Inheritance is 99.9% of the time (e.g. always...) the wrong decision.

Inheritance, after-all, is one of the strongest forms of coupling you can introduce into your code ;)

There's usually a way to use composition to achieve the same thing.


Yeah, I kind of wish that hadn’t been such a big part of my formal education.

I only did some CS and so much of it revolved around inheritance in Java that I found myself looking for opportunities to use inheritance in the wrong places.


I feel you there. Been there done that 😋


James, didn't you do a Composition over inheritance post?


I don't think so... but it's something I've had in my head to do someday!



Composition is 99% of the times a better choice :D


The Template pattern happens a lot more than just 0.1%


Agile and Scrum are dumb. Daily stand-ups, planning poker, scrum masters and all that other stuff is a waste of time, money and office space. So far I'm yet to see this pseudo process help any team that is not good in the first place to get and perform better.

Also Agile is the worst misnomer in the software dev world. There's nothing agile about Agile.


What I "love" is when you're in a retrospective and you're asked for ideas that would make things better, but when you state your idea you're shouted down because "that's not agile".

Also, the idea that the amount of effort required is equal amongst developers is nonsense.


What Agile are you referring to? The one from the Agile Manifesto? Or the one most companies claim to practice?


Since I'm speaking from experience, I'm guessing it's the latter. But who cares about some unicorn in the sky if all we get is the real thing?

One of the first things which goes out of the windows with most companies which adopt a Scrum way of working is the agile part of it. But there are companies which do adhere to the agile manifesto.


Daily stand-ups serve the purpose of putting the team on sync. If your team is 3 people in size, then they are ridiculous.

Planning Poker, if done correctly serves a very important purpose as I explain here:

Real Scrum Masters (not a person who used to have the title of project manager) serve the purpose of helping the team organize who does what and taking care of any lack of clarity on the stories.

Scrum is the name that Agile receives when applied to software development. Agile is getting feedback as quickly as possible about the decisions you make. I feel that if anyone works using the alternative, waterfall, then that person is the worst engineer it can be.


From my experience a good team keeps themselves in sync naturally. There are tickets/issues, Slack, email, old fashioned p2p talking. There weren't many stand-ups so far, where I learned something interesting or got synced up. Usually it's just a reiteration of the stuff that I already know or something I'll get to know later during the day anyway. People just say what they did or going to do. If it's interesting for me, I already know it, otherwise I don't need to hear it.

I think the team which lacks clarity in stories doesn't need a scrum master, but rather learn more about the product they are building and talk more to their teammates. You don't need an extra freeloader on the team to help with that.

Agile and waterfall are not the only alternatives. I don't have a name for it, but another approach would be a "natural organic team approach" where everyone is just getting their and common shit done, where the communication and planning happen naturally. In the right setting it just works. I've worked in the company, believe it or not, where we had about 40 people working on the product and there was not a single meeting dedicated to project management. We did have meetings, but they were extremely rare, like one in 3 months to announce something serious usually. Like a new future project, or that we're moving to a new building, but not to decide who works on which task. And in that company I and the whole company was amazingly productive, much more productive than in any other agile or process-less company I worked for before or after.

And in that company I and the whole company was amazingly productive, much more productive than in any other agile or process-less company I worked for before or after.

That is the point. You want a reproducible system to make any team productive, not leave it to chance.

IMO introducing this type of agile process IS leaving it to chance, as it has no influence on the result. Something else has to be done to change improve things.


They're big business now and command enormous groups and conferences. No matter their merit, they're not going anywhere because people out there sell agile to companies and teams for a living.

  1. Middleware frameworks are way overrated and overused
  2. Not everything is a problem that should be solved with software

Hallelujah for number 2. Tell it to Silicon Valley VCs 😂

What do you mean by middleware frameworks?


I wish they'd listen to me!

By middleware frameworks I mean things like React, Vue, etc, that are a javascript/front-end interface for the backend; they definitely have a lot of great uses but I think there's starting to be this idea that you have to have one when most sites don't, actually.

I wish they'd listen to me!


I think there's starting to be this idea that you have to have one when most sites don't, actually

Yeah I agree! I just wrote this comment about classic web apps with server rendered templates:

I see them often ignored in the context of new web apps.

It's like people don't even try anymore, they go straight to SPAs even if they don't really need to...

Even some articles about web development in general tend to set SPAs as a given and "older" MPAs as a deprecated alternative.

I think it goes in the same direction as yours...


Damn, I agree with both big time!


A left curly bracket that marks the start of a code block should be placed on a new line.


You're right. This is unpopular 😄


C# or JavaScript? C# I agree. JavaScript no, why!!!


Any language using curly brackets for code blocks. Simply because with a new line the left and right curly brackets align, oh the beauty of alignment!
But your opinion must be even more unpopular, that you prefer new line in one language and not the other.

It's the way I learned each language and I think most of the JS I work on has enforced linting.

I had a colleague who was putting the curly bracket on the same line, for compactness, but then was starting the code block with an empty line, for readability.

I used to like my brackets to match, but lint disagrees and so do most programmers. I have my principles, and if you don't like them, well ... I have others. Life is full of disappointments and sometimes it's easier just to go with the flow.


I'm the same - some languages are fine with it on new lines, some are strange.

Most importantly though is that you are consistent. Don't be like PHP PSR-1 and have classes and functions one way but if/for/while etc another.


I live in conflict on this one. In PHP, when it's a class, I always add the brace on its own line, but for a function, I bundle it with the function name. On the other hand, when writing JavaScript, I never put the brace on its separate line. :deal_with_it:


Nope, I don't need to deal with your inconsistent syntax. 😋


curly brackets are syntax trash, they are for the compiler...
humans use indentation


Languages that rely on indentation scare the bejeezus out of me! 😥


JavaScript is the greatest language of all time!


Have you tried any others? 😎

No, seriously, I’d like to know why you think so. Maybe you could explain why.


I started with basic on the C64. Then Amiga Basic. QBASIC. Cobol. C. C++. Perl. JavaScript. ASP. Visual Basic. VB.net C#. PHP.

Too a Haskell course but haven't done anything with it.

So I guess... Yes.

I’ve used a couple of those languages as well and it is obviously a very personal opinion.

So again:

Maybe you could explain why.

I am honestly interested.

Maybe you could explain why.

  • The community. Npmjs, etc. JavaScript has the largest community.

  • don't need any tools to get started. Can run in just a browser, which everyone has.

  • easy to share your programs. Send people a URL and they can see your code run.

  • runs everywhere. runs in the most popular app that everyone has, the web browser. Runs server side. Can be used to build mobile apps and more.

  • flexible. You want OOP or FP. You can program however you like.

  • backwards compatibility. The code you write today will still run in years to come.

And probably more I can't think of right now.



I would say: Good points. So it’s more about the ecosystem than about the language itself. The above is probably also true to e.g. TypeScript, isn’t it?

Because TypeScript can leverage most of what JavaScript offers, it had a huge advantage over other languages. One minor difference is it needs a bit more tooling ad it doesn't run native and must be compiled to js.

Good points dude. Also, you can use it to make art with P5.js, and ML with Tensorfow.js :) that's awesome!


For the backend? 100% agreed (and I have tried many others). After all these experience, Node is still my num. 1 choice.


The verbosity of Java doesn’t hurt a bit.


I recently had to fix a catastrophe of an Android application, on a tight schedule, with little Android programming experience, and a rusty Java, and I agree: what’s the problem with having to instantiate an anonymous class from an interface to implement an event listener, when you just have to type the first three characters of the listener method to have the IDE write the whole thing? And when you read the code, your brain will just skip from setOnClickListener to onClick anyway.

In the end, the help you can get from the IDE because you’re using a proper language like Java trumps the verbosity.

And that was in Android Studio: it’s a proper IDE, but it’s not that good.


Oh, I‘ve got another one: Eclipse works fine for me. :-)


1) MVC is a terrible design pattern. The separation of concerns is absolutely backwards. It separate directly related items that would most likely be worked on together, simply because one is visual and the other is logical. Instead, we should go back to the time when code was organized by access and usage. The logical code and visual template for a given URL should exist in the same folder, not separate them.

2) these modern "URL routers" are very slow, bulky, unnecessary, don't scale well in hardware, or scale to larger teams! It causes a "too many cooks in the kitchen" problem


MVC isn't a horrible design pattern. It's because they're trying to implement it into things like PHP (which can't be actually done). But in my experience while everything isn't perfect, MVC can increase your development speed, and keep things separated and clear in your head. At least it has for me.


And yes, the modern URL routers usually use regular expressions and fancy stuff to make URLs pretty. While it does make it slower, a lot of these sites aren't going for performance, they're going for development speed, and I have both built and used "URL routers".

Their goal is to implement something in the language the developer is familiar in, making it easier for them to write code.

If you were expecting 10,000+ requests a second, then yeah, you wouldn't want a "URL router".


Both of those things above are directly related for me. There are better design patterns out there that are simpler, easier to implement, easier to understand, and significantly more performant. Yes, all of these, all at the same time.

I get why these tools work for others... but the whole point was "unpopular opinions", which mine is. ;) And it is based purely on 20+ years experience as a software engineer developing software at pretty much any scale (microcontrollers to fully distributed server clusters across multiple datacenters)

As time permits, I've been documenting all of my notes on this, but it is a very lengthy process. But it essentially comes down to attempting to create a zero-boilerplate-framework. Pretty much just create a new file, have the text "hello world" in it, nothing else, and it works. Need more? Simple enough to add more. URL Routers and MVC frameworks add additional and often unnecessary extra boilerplate to get the same job done.

I truly believe our ultimate jobs as software engineers should be to simplify tasks as much as possible, not add more barriers to entry with frameworks which get in the way of simple tasks.

Hmm, that's very interesting. How would you go about making a framework that simple, but flexible at the same time?

If you're working a project like this, I'd love to see it.


True, but the best routers should compile those regexps to have near zero overhead ✌🏾

Oh? You can compile regular expressions ... ?

Sure, for example:

Basically you turn the regexp into a cached internal object that has very little overhead during the pattern matching.

That's neat. Thanks! I didn't know you could do that. :D

It's very useful if you have to match a regexp in a loop for example. You only construct it once :)


All design patterns are terrible.... for problems they weren't meant to solve. I think a more general issue here is people; we learn a new thing and want to apply it everywhere.


Managers in software with short or no coding history are the worst.


Some of my best managers were non-coders.

I find the worst managers are those who used to code, but they weren't very good and are still bitter about it.


I find the worst managers are those who used to code, but they weren't very good and are still bitter about it.

This is what I kind of wanted to say with "short coding history", because usually when someone is not very good at coding tries to switch roles pretty soon.


Not sure this is unpopular, but a good one nonetheless


My unpopular opinion is that this really doesn't matter at all and you should have something that formats your code for you.


I use tabs for indentation, and spaces for alignment. This way, I can switch tab size and still have everything align as it should.


React is massively overused, misused, and over-promoted


Thank you for saying that. React is a terrific tool with terrific programmers around it but I feel everything about it is over hyped.

The counter argument for my previous statement: if it generates this much enthusiasm from its users, they have definitely done something right.

I can't just feel the groove. To each their own, when I went through Vue's docs I knew it was the tool for me, when I went through React docs I wanted to close the tab and go do something else :D

What bothers me though it's how some people (definitely not the fault of the core developers) market it as the one true ring that will give you invisibility and super powers. The counter argument: I'm this close to running naked in the street shouting for the second coming in the form of Rust and WebAssembly so I understand what supercharging factor have tools your brain fits in when you discover them ;)

There's also the marketing aspect to consider: once a large enough pool of companies/people adapt a tool, a lot of others follow suit just because it's popular and if the tool it's good enough, it sticks.


Nooooo, React is great!
And so is the hydraulic press I bought at Christmas to deal with that bag of walnuts.


1) That unit tests are believed to be necessary to create good software is a damning indictment of both industry and academia. Decades have been spent researching things like formal methods and static analysis and unit tests are the best we can do?

2) Having a minimum code coverage requirement leads to a bunch of tests that do little more than test the VM/runtime, not the code that's supposed to be being tested.

3) Having unit tests is nowhere near as useful for refactoring as people claim.

4) Unit testing became fashionable only because people started using Ruby on Rails and they needed to make up for the lack of static types and billable hours (1/4 of the time compared to java meant a 1/4 of the amount of pay).


To a very large extent I agree with this. Unit tests are a horrible replacement for a lack of static typing. That doesn't mean they aren't useful, but if you're using unit tests to prevent breakages during refactoring, do yourself a favor and just learn a freaking statically typed language.

That is, learn literally anything other than JavaScript.


You should only unit test units which are worthwhile to test. No need to test setters and getters unless they contain business logic. Requiring a minimum coverage is bad. But aiming for a minimum isn't.


You're probably doing tests wrong or I'm doing something you wouldn't call tests. That's the only logical explanation I can think.


Unit testing was in wide use LONG before Rails.


I didn't say unit testing didn't exist. I said it wasn't fashionable. No one in 2005 would have been accused of not being a professional if they didn't do unit testing.

Having been there, I disagree, and submit that our contexts are probably different.

I was there too. I'm so old I remember when unit tests would have been called white box tests and looked at as an inferior form of test as you can see the code.

I can even remember being told how in the future all we would need to write is the formal spec and the computer would work out what the executable code should be. Needless to say that future never arrived.


DRY does more harm than good.

(Yes, that is deliberately bait-y, there's a lot more nuance to it in reality.)


This is a safe space for being a bit bait-y as long as everyone is self aware enough. 😁


For everything that goes beyond one code base, I’m in. DRY at module, service or system level has a lot of serious disadvantages, the biggest of them is creating dependencies.


100% dependencies are the worst!


I'm kind of hoping at least one of these isn't unpopular ...

  • I still haven't seen Entity Framework add value
  • Visual Studio is amazing
  • Too many things depend on node / npm
  • Not everything needs its own cli
  • WPF doesn't (didn't?) get the love it deserves
  • Programming is mostly googling "how do I X in Y"
  • There's a lot of fads without substance and too much time is wasted on them (buzzwords, "we use X now, Y is SOOO last year", ...)
  • Not working at a shiny startup is also cool
  • Software has gotten much better over the years and most software is good and pleasant to use