Software development topics I've changed my mind on

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space.

I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them.

Things I beleive:

- If you're picking up on code-style in PRs then your toolchain is backward.

- If you're changing linting rules every month then you're focussed on the wrong things

- It's better to have a consistent style than a perfect style

Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?

In my opinion, I think the author is criticizing bike shedding [1] rather than meaningful decisions. Of course some people will differ on whether a decision is one or the other. But as a whole, not sweating the details is a good quality to have whatever road in life you are on.

[1] https://en.wikipedia.org/wiki/Law_of_triviality

Thing is, you can care for the craft, but let the code style and linting tools do what they do best and don't stress over them. Code reviews are better now that there's tooling that automatically checks for, fixes, or marks common issues like code style so the reviewer doesn't have to do anything with them.

That is, I'd argue the "stressing" is not about what these tools check, but about the tools and their configuration itself. Just go with all the defaults and focus on bigger issues.

If you want to compare to artisans - they were stressing about details that customers see, details that customers don’t see were to cut corners on.

Making fuss about indentation in code file is not artisanal. It is insane weirdo if we are charitable and if not clueless and childish.

To me "craft" is about keeping code efficient, scalable, extensible, well-tested and documented. Code style is more about what naming convention to use, tabs vs spaces etc. - it's nice to have it consistent, but no need to spend more than 5 minutes arguing about it.

There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that.

For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.

it's the best comment in the entire post IMHO and made me LOL

Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it.

Greenfield, absolutely design up front you lucky devils, but iterative is the way otherwise.

Most programming is actually figuring out what already exists and what (and more importantly: why) the requirements are. This is best done long before a single line of code is written.

I think the author is taking a wider view of "programming" than the actual writing of code as the end product. Some of the most important work I've done is spend the time to argue that something doesn't need to be done at all.

Always think bigger picture than what you're immediately working on. (I don't mean that you can't ever just focus on the problem you're trying to solve for, say, hours. I mean you can't focus like that for the entire time you're in that development phase.)

Think about design and code (and functionality!) before you start coding. Think about design as well as code while you're coding. Think about design, code, and functionality while you're testing.

I assume there are people who are able to have those eureka moments before writing any code. I definitely write a lot of code before figuring out the final design but always think I should be designing more.

ok that sounds bad, you should have the option to go back to design, but depending on what point you find that issue, depends on how much time you have wasted?

I'm kind of wondering where the "mixed experience levels" part comes from. What is it about more homogeneously skilled teams that makes them less susceptible to the productivity boost that statically typed languages give in large code bases?

UX really is everywhere, once your eyes are opened to it.

I think the size of the code base also matters: bigger size = having types is more important.

There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.

[dead]

Code style is one thing - formatting that is - but there's others like how features are implemented tend to change over time and with different developers as well, which is difficult to automatically test and hard to keep in line except with good code reviews, but for that to work you already need to install a culture of consistency, which also means that innovation may be stifled and developers demotivated (e.g. because the better solution requires the 100 existing solutions to be rewritten, which is too expensive or requires a whole team to be blocked until it's done).

Consistency trumps a lot of things IMO, but not everyone is on board with that... myself included, I'm guilty of breaking with my own consistency all the time.

I've grown to be a big fan of opinionated linters like gofmt, rustfmt, black etc. They avoid so much time spent disagreeing about code formatting and personal preferences. Instead engineers can do mutual grumbling sessions about weird formatting choices they see it do, and move on.

It was botched from the start because there's so many opportunities for unchecked exceptions as well. Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. Divide by zero. And so on.

You also have a problem similar to "monads and logging": if you want to log from anywhere in your program, your logging function needs to be exception-tight and deal with all the possible problems such as running out of disk space, otherwise you have to add those everywhere.

I agree, although I would like to point out Java usually gets the blame for what was actually an idea being done in CLU, Mesa, Modula-3 and C++, before Oak came to be and turned into Java.

Additionally, the way result types work, isn't much different, from type system theory point of view.

I really miss them in .NET projects, because no one reads method documentation, or bothers to have catch all clauses, and then little fellow crashes in production.

> adding it to your own function signature

This is precisely why they are so bad: checked exceptions must not be allowed to be used outside the package (or jar, or whatever, just limit it) otherwise they cause non-local build failures in all dependencies. They're fine if you are developing the artifact that's going to be deployed.

> They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling.

Syntactic sugar it needs is an easy way (like ! prefix) to turn it to a runtime exception.

Procrastinating on exceptions is usually the correct thing to do in your typical business application - crash the current business transaction, log the error, return error response. Not much else to do.

Instead the applications are now littered with layers of try-catch-rethrow (optionally with redundant logging and wrapping into other useless exceptions) which add no benefit.

Checked exceptions as an idea are great (Nim’s usage of something similar is excellent) but yeah Javas particular implementation was annoying and easy to avoid, so most did.

I mean on paper they're a good idea and well implemented etc. However, the main two flaws with exceptions are that one, most exceptions are not exceptional situations, and two, exceptions are too expensive for dealing with issues that aren't exceptional like that.

> Alas, many caught it and wrapped it in a generic RuntimeException.

Actually sounded great right up until this point. Deal with it, or explicitly acknowledge that you do not. It's honest.

Apparently other developers are why we can't have nice things.

Nah, I think having a monadic Maybe/Option type and first-class support for it is the correct solution. Exceptions are fundamentally flawed.

From “The Cathedral and the Bazaar”:

> # 3 “Plan to throw one away; you will, anyhow.” (Fred Brooks, “The Mythical Man-Month”, Chapter 11)

> Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.

https://en.m.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

I've made an opposite progression from the op. I was a strong believer of upfront design, but now value iterative approach as you do.

For the first try, hack together something working, you'll learn things along the way, validate/disprove your assumptions. Iterating on this will often bring you to a good solution. Sometimes you find out that your current approach is untenable, go back to the whiteboard and figure out something different.

Its wrong in those day , exploratory coding is better for dynamic languges like python using jupyter notebook , and then do proper coding after exploratory step..

It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...

One job I had, we got handed a code base with at least 4 different reinventions of an ORM in it.

It became clear that each developer who'd worked on the code had written their own helpers to avoid direct SQL. It took a fair bit of persuading leadership, but the first task ended up being doing a huge reactor of everything SQL. Unsurprisingly enough, lots of bugs got squashed that way.

It’s the devil I know and for most of my projects I’ll likely never forsake ORM for raw SQL.

Depends upon the ORM. Like all frameworks, a really good one is a significant productivity boost while a bad one is faworse than none at all.

I agree with you, i'm much more on the "try stuff out" scale vs. formal methods. That being said, i've worked with people who are the other way and still very effective. I think this one is more of a trade-off or personality thing than something that's "true" or "false"