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!

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

Art!

  • 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.

 
 
  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.

 

😂 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. ...

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.

 
 

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

 
 

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.

 

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!

 

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.

 

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.

 
 

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.

 

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!

 

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.

 
 

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 😬

 

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.

 

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.

 
 

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!

 
 

Agreed.

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

 

The Template pattern happens a lot more than just 0.1%

 
  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...

 
 
 
 

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.

 
 
 

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

 
 
 
 
 

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. 😋

 

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.

 
 
 

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

 

Languages that rely on indentation scare the bejeezus out of 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 ✌🏾

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.

 
 

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.

Cheers!

Thanks!

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.

 
 

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

 
 

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.

 
 

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

 
 
 

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

 
 

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.

 
 

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.

 

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.

 
 

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.

 
 
  1. I gave a talk about Visual Studio Code in my company yesterday. Among my colleagues I am the only one who uses VSCode and I think there is no reason for web developers to use WebStorm.

  2. I don't think it makes sense to host your own database when you can use cloud solutions.

  3. Don't get me wrong, I really like Docker and Kubernetes, but I think for some projects it is okay to deploy them on bare metal.

 

1 - Totally agree.

2 - Price, I can have a couple of powerful dedicated servers for 150€ per month and make a solid database setup with replication and backups in there that can handle thousands of connections per minute while the same on AWS would cost me around 900€ per month.

3 - Again cost. The recovery time on a crash and the ability to quickly move(a couple of minutes) everything to another machine are priceless.

 

Re: 1

Better code completion, search and code navigation are worth it.

 
 

There is no justification in using Yoda Conditions in PHP or JavaScript.

In those languages, you should always use the === operator anyway, so if you can train yourself to always use ===, then you don’t need a hard to read safeguard against writing = instead of == in an if statement. And if you can’t train yourself to always use ===, but you can train yourself to write Yoda Conditions, then you’re weird.

Also, Yoda Conditions for any other operator (!==, <, >) are evil.

 

I'd expand that to a lot of other languages; even C based. Any compiler worth its salt can warn on "assignment in a boolean context" these days.

 

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.

 
 

Type coercion is fine if you know what you're doing.

 

It never was. When you know what you are doing you don't rely on such a thing.

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

I read through A LOT of things here but I had to sign up just to reply to your bullshit.

Marco, you can vehemently dissent obviously but your comment seems a bit unwarranted, don't you think?

 

Type coercion is fine.

Implicit type coercion is the worst feature of all.

 

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
 

I still haven't seen Entity Framework add value

I'd say the same thing about Hibernate/JPA on the java side. If anything, they end up causing more problems than they solve.

 

Not unpopular, at least with me.
I also like VS (best IDE to my mind) and WPF (way better than WinForms were).

 
  1. Ligatures are weird and don't make code easier to read.

  2. You don't need to use bleeding edge/new shiny code features to have a good time. Especially for new operators when the existing method wasn't even difficult or time consuming.

  3. For languages with braces, while they can be optional for one line if-statements etc, please don't...

  4. SASS isn't the solution to CSS problems. Sure it can do some different stuff but just switching CSS to SASS doesn't solve poorly written/structured CSS.

 

Ligatures are weird and don't make code easier to read.

Intellectually, they're just another glyph; no different than any other letter. I can't read Russian, that doesn't make it unreadable. Everything is hard to read until you learn to read it.

Emotionally, yeah, I don't use them either. Hipster nonsense. ;-)

 

True while they are just another glyph, even if I was use to reading them, they don't make code any easier - they are just another way of representing something that wasn't even a problem.

It is kinda like a solution in search of a problem.

 

1) Object Oriented Programming is overrated and often not the most fitting choice.

2) Code does not mater, solving problem does.

3) We all loves our tools (ide, linter ...) but the fact that we search new one or way to make them better is a proof that in the end, they sucks one way or another.

4) Git is not that of a great tool. We use it more because it's the biggest on doing what it does.

5) JavaScript is ultimately misunderstood: it's not an OOP language, the core of it's object's model is prototype and lot of people try to make it otherwise.

6) I am being too much?

Anyway, it's not written in stone and only represent feelings of my present self (will be happy to discuss any point and even change my mind).

 

5) JavaScript is an OOP language. It's object system comes from Self. Classes and objects aren't the point of object oriented languages. The key idea (at least according to Alan Kay, who we can probably take as an authority on the subject) was that you could summon mathematical structures into existence with almost nothing if you can orchestrate actors, each implementing their own language. Classes and methods on them were the particular implementation they arrived at for Smalltalk as an implementation of this.

 

It seems that I effectively used the wrong words here. JavaScript indeed use object. The object pattern is prototyping. But I still think that JavaScript is not "in essense" an OOP Language but a language proposing it: the language does not favorise the use of object and "this" does not refer to an object the same way that any other language (but the prototype it's currently called in) and does not make the thing easy.

We can object to that that functions are kind of "object" themselves.

I realize though that my knowledge on this particular subject is not that strong, so is my position on it. I'll check the work of Alan Kay that you mention earlier. Thanks a lot.

Clarification of my mention of Alan Kay: he invented object oriented programming along with the rest of the Smalltalk group at Xerox PARC.

this in JavaScript behaves the way it does in any other prototype based language (as I mentioned before, see Self). Self and its lineage were part of an attempt to make an even purer object oriented language that Smalltalk. In Smalltalk you had objects...but you also had classes, which were somehow different. They were objects, but were part of a totally different inheritance hierarchy. Self asked if the classes were really necessary, or if they were baggage carried over from earlier programming experience. The answer at this point is quite clear. Classes are unnecessary, but it's really hard to get people past the baggage and comfortable with conjuring objects directly.

For completeness, there's a third branch of object oriented programming represented by Common Lisp's CLOS based on structs and generic functions with multiple dispatch. It turns out to be an even more powerful approach, and this isn't a thing in that system at all. That branch, if you take it seriously and work out the mathematics, leads to Stepanov's work on generic programming and the C++ Standard Template Library.

 

1) Depends a lot of what your code aims for. It is an MVP that will be erased after the startup gets funding or closes for the lack of funding? yeah, OOP or not doesn't matter.

2) Solving problems with the most optimal solution possible at the minimum cost possible. Taking into account that more than 95% (or more) of the cost of software is on the maintenance part (add this or that, change X and fix Y) and taking into account that OOP is the easiest way for most humans to work, this also clashes with point 1.

3) Is more a sign of how little we know about the art of solving complex abstract problems.

4) totally agree. And I would add that most of the problems it solves were introduced thanks to it.

5) what is an OOP language? a language that uses objects. What is an object? the representation using code of an abstract entity from a problem we are solving. Therefore for me, there is almost no language that isn't OOP. Most people call a language is OOP because it uses Classes but I find that way to simplistic.

6) Oh, no! please continue.

Anyway, it's not written in stone and only represent feelings of my present self (will be happy to discuss any point and even change my mind).

Words to live by.

 

1) I totally agree. What I was trying to do (and it's not only OPP in fact, but a lot of stuff) is that we should use the right tool for the right job and not the shiniest tool because everyone love it.

2) I was trying to express that the beauty of your code and the absolute awesomeness that we can find in it is not as relevant that the problem you seek to solve.

3) That's an interesting thinking, I'll dwell in it someday.

4) Some other tools (like pijul) deserve a little lookup to broad a little the landscape of vcs.

5) I tend to believe that OOP is a paradigm revolving around object. It's not that objects exist in it but more than everything is done to promote them. For instance Java urge you to manage things through object. Object become de-facto the "orientation" taken by the language. Other paradigm, like functional or ECS, or not focus on object as a "core" concept of programing. As such, object are just a convenient way to pack data altogether in those paradigm rather by being the central gear of it. At least it's the way I see it.

But my vision may be biased or even uterly wrong.

6) Ok...

7) Top 10 are overrated, top 7 is the way to go.

 

clean code is not fast code!!!!

Let me explain more, clean code can be fast and it is good to have code that will be easily understandable but my point is that you could have messier code that is faster and fix its readability issues with clear well thought out comments.

So just because a piece of code is "messy" does not mean your cleaner code is faster.

Speaking from the interpreter side of things

 

Generally, it would be good to explain your statement a bit.

I would say this is not always true as good optimizing compilers can turn clean code (whatever exactly you mean by that) into very fast code.

But it definitely can be true in certain situations.

However, the question is: Does it matter? My first goal
Is always to have maintainable and understandable code. I optimize only when I need to. This might result in less readable code. But I only do it if there is a serious performance problem or the requirements are not met.

 

You're not ALWAYS going to maintain your code. The better code you write, the lesser other person have to struggle.

 
 
 
  1. Maybe not unpopular, but programming interviews are a joke and hardly correlate to actually hiring good people

  2. Big companies are important to our ecosystem and help by giving stable jobs, good pay, and reasonable benefits

 

1: true. I don't know about America or Europe, but Ukrainian/Russian programming interviews are often a clown fiesta. Interviewer can ask you to build binary search tree and count all methods of an Object class in Java while in reality you are going to code HTML templates and write CSS lol.

 

Software/code is a liability, solutions to problems and your bank of knowledge are the real assets.

Every year you or your employer spends money maintaining an aging codebase. Bugs, vulnerabilities, support tickets. Strictly (and realistically) speaking, code would be in the "liability" column in an accounting book.

On the other hand, you or your employer has a large amount of people who are subject matter experts on your product. If you put every one of those people into a room, and magically herded those cats, you could probably come up with a better product. They know why a specific quirk exists, they know why one piece of code has to be horribly complex.

I've learned two things from this. Invest in people, not code. I hate my code, but I love what it does.

 

I really dislike JS and how it's spreading everywhere. Everyone seems to be building stuff on top of Node or Electron, leading to bloated, RAM-consuming programs that do simple things that don't justify the resource usage.

I believe there's also the factor of a high influx of bad devs, just like what used to happen with PHP some years ago.

 

I would use the IRC gateway for Slack if I could. I don't need anything better for chats. I can chat without GIFs.

I actually try not to use Electron apps, and look for native alternatives.

 

Git branches are only useful on public repos where you have contributors from outside the team. Used on any other scenario makes you a bad engineer by delaying integration, therefore, increasing costs of production.

 
 
 

Your software skills do NOT matter, your way to promote those skills do matter a lot more.

You can replace the word "software" with "business" as well.

 

Squarespace is good enough for most small business websites and it doesn't need maintenance. That being said, it is unlikely someone without web savvy will be able to make a good website with Squarespace.

PHP is a good enough tool for most sites.

jQuery is still an alright option in 2019.

Learning a framework before learning the underlying language is fine.

Most websites never need to scale.

Project management tools are little more than security blankets and don't actually solve project management problems.

 

Thanks for some love to jQuery. Not every website is SPA, it's okay to use jQuery and his tons of great plugins for simple JavaScript tasks.

 

jQuery's API really lends itself to developer productivity. In the past year I've moved away from using jQuery on small projects because I don't want to load the extra kilobytes, but I don't think I would have made it through my first year of programming without being able to leverage how simple jQuery makes interactivity.

I hope that more developers recognize how much power it gives beginner developers before they shun the library in favor of tools like React and Vue. Both of those tools come with a fair share of SEO problems, and client-side rendering can kill performance on slow connections and inexpensive phones. jQuery largely doesn't have these problems.

 

Software used to have a personality that matched the platform it ran on. Mac apps felt like Mac apps, Windows apps felt like Windows apps, iOS and Android apps felt like they were at home there. My unpopular opinion is web development, and its bastard child "cross platform web apps" have killed the personality behind software when the majority of development went into building for a browser instead of a platform.

 

My users' experience is far more important than my development experience. The industry has forgotten. Evolution of apps and the web has stalled while ever changing development processes devour teams. New ways of thinking about software languish under the complete rejection of risk from first user interview to deployment.

 

Given the current professional jobs I seem to have had these past 15 years or so, these are my "not popular opinion" with colleagues:

  • Using Unix/Cygwin command line and bash/python/awk/sed to automate things.
  • Using Emacs (or Vi) instead of Visual Studio.
  • Using git instead (or on top) of Perforce.
  • Preferring not to use a debugger, but rather writing tests (TDD) to discover and fix bugs.
  • Garbage collection has it's place and uses, it's not an abomination to be avoided.

Can you guess the particular part of the Software Industry I'm in?

 

Preferring not to use a debugger, but rather writing tests (TDD) to discover and fix bugs.

That one hurts...

Writing tests is meant to help regression cases and in TDD, shape the application code. Debuggers aren't meant to be replaced by tests, they help you narrow the problem down so you easily see the code and conditions of a bug. This should (but maybe it hasn't in your experience) help you get to the source of the problem faster.

 

Okay, granted I'm talking more about a project on which I have full control and knowledge. On other projects, especially where I'm unfamiliar and/or there are less tests, I'll use a debugger more.

Also true that in some cases I do get out a debugger, but increasingly over the years I tend to already have a test for the code in question, and often it's simply obvious what's wrong (the test has failed on an assert), so I just fix the code because I already know what's wrong.

The time I do pull out the debugger is when either a) I don't have a test (I should write one then - so less likely) or b) it's making no sense at all and my mental model and tests don't match the code.

I'm going to say that in about the past 18 months I've used a debugger three times.

Stats on project I'm working on (alone):

  • 288000 lines
  • 1800 files
  • 1367 unit tests
  • 7000 test assertions

Hence: I prefer not to use a debugger, but rather write tests.

Bonus: Once you fix a bug by first writing a test that fails, you know when you've fixed it, you know you'll know if you ever break it again, and you have one more test.

Just out of curiousity now, what is the lines/files of code split between tests and application code?

And also curious, what programming language?

  • The tests are in the same file as the class.
  • Approximately 65000 lines of tests, so about 20% is test code.
  • The programming language is called XXXXX (*)

(*) Name redacted because it's a new unreleased and in-development. Doubt it will see the public eye for a few years or more (if ever). It is however written in itself because "Dog Fooding" (and heavy testing) is the only way to hope to succeed at such insanity.

FYI - The counts are pretty inaccurate, I didn't use sloc tools, just find/xargs/wc. I'd say there's about 15% of blank lines/comments/junk at a guess.

I guess we can add one more unpopular software opinion:

We do need Yet Another Programming Language!

 

You take time to build a ci/cd pipeline - sweet!

You took time to get your build green - sweet!

You did not take time to make your build faster and now its taking up 6gb RAM per run and 2.5hrs to build - not so sweet!

 
 

I wholeheartedly disagree with this statement. Well done! 😉

 

I'll bite :)

Just the frameworks, or DI as a whole?

 

Just the frameworks. I think I should write about this as soon as I find the time.

 

Server-rendered templates now, server-rendered templates forever!

 

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.