I am not smart enough to effectively code with certain languages and design patterns and that’s ok. There is nothing wrong with accessibility being prioritized or with making tradeoffs for the sake of reducing complexity.
Programing is a lot less important than people and team dynamics
Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.
Been with a lot of codebases that had no unit tests at all and everyone was afraid to change anything because the QA process could take weeks to months.
The result is you have a codebase that ages like milk.
Only if the code base is well tested.
Edit: always add tests when you change code that doesn’t have tests.
And also try to make tests that don’t have to change if you refactor in future (although there are some exceptions)
Doesn’t everybody agree with this? I really never thought of it as a hot take.
I highly doubt most corps do
Corps != people.
People just pass the buck and nobody stands up for what is most correct
deleted by creator
Most calls I have at work are like group therapy sessions, as everyone has ideas of what they believe is correct, but they know if they keep pressing with management or take the time to do what is right, it won’t go well for them.
This is coming from a guy who lasted a year and a half in the office. Sounds like it’s a systematic issue…
deleted by creator
This
deleted by creator
Today I removed code from a codebase that was added in 2021 and never ever used. Sadly, some people are as content to litter in their repo as they are in the woods.
Our company motto is: “leave it cleaner than you found it”
We used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it
Yes please. Many times when I add a feature I end up refactoring some of the code first to better accommodate it.
thank_you_michael_scott.gif
The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.
If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.
However, engineers who rely solely on comments to explain their code, are bad at writing readable code.
Possibly, but I’d prefer this scenario over the other.
Let’s take this one step further. I should be able to get the core ideas in your code by comments and cs 101 level coding (eg basic data structures, loops, and if/then).
Self documenting code is infinitely more valuable than comments because then code spreads with it’s use, whereas the comments stay behind.
I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.
One of the things I tell my juniors is, “this isn’t the 80s. There isn’t an 80 character line limit. The computer doesn’t benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code.”
80 character limit is helpful though when you need to have many files open at a time. Maybe 100 is more reasonable. Fighting indentation is important too.
I, too, remember the days before ultra high definition ultra wide monitors.
I thought this argument was bogus in the 90s on a 21" CRT and the argument has gotten even less valid since then. There are so many solutions to these problems that increase productivity for paltry sums of money it’s insane to me that companies don’t immediately purchase these for all developers.
You have a point, devs should be using multiple large monitors. I will often need to have 3-4 files open at once, plus some browser windows. Having some limit on line length helps with this and for fighting code complexity.
The most important thing is comprehension. If something is too long and the length makes it less readable then it is too long.
But if having 3-4 files open at the same time makes it harder for you to comprehend a single file because you can’t get the full picture, that’s on you.
I have a massive ultrawide and I still 100% believe in line limits. Long lines are harder to read in general but even with a limit of 100 I frequently have 3 files opened next to each other and I can’t read entire lines easily. Line limits just aren’t about the size of the monitor and I can’t believe people still say that.
I understand the concern, but readability and comprehension are way more important than line length. If the length impairs readability, it’s too long. Explicitly limits are terrible. Guidelines, fine.
Ultimately, you do you. I still think your crazy and I think your argument is poor.
Yes a strict 80 character limit would be bad but that’s why modern formatters aren’t strict and default to 90-100.
I’ve pretty much never seen code that would have been more readable had the lines been longer than that.
My main argument is still that shorter lines are more readable. I just think it’s a bullshit argument to say that long lines are fine because large monitors exists. I don’t see how that makes me crazy.
See, I think length limits and readability are sometimes at odds. To say that you 100% believe in length limits means that you would prefer the length limit over a readable line of code in those situations.
I agree that shorter lines are often more readable. I also think artificial limits on length are crazy. Guidelines, fine. Verbosity for the sake of verbosity isn’t valuable… But to say never is a huge stretch. There are always those weird edge cases that everyone hates.
There’s no such thing as self documenting code, unless every method and variable name has the word “because” in it.
Anyone can read what the code does. The comments are there to answer why it does what it does the way it does.
Why is invariably lost to time, if it’s not committed to a comment here and there.
This is a pretty ridiculous position to take but if you believe it then I’m glad you write the comments you do.
There is an argument that commenting on the lack of expected code is valuable for this reason, but it certainly isn’t true in all situations.
We can agree on “not all situations”. Often the answer to “why did we do it this way?” is blazingly obvious, and no one wants a comment.
But we all know that sometimes the “why” isn’t obnoxious at all.
As far as I can tell, developers who do believe in self-documenting code either haven’t learned the power of “why?”, or they have a secret technique for encoding “why?” into their code structure.
If it’s the second thing, I would be delighted to be brought in on it. (No sarcasm. Maybe I’ve missed a trick here.)
I’ll answer in a couple of different ways.
-
If I am writing library code my why is you have an end use and I don’t care why you use it and you don’t care why I wrote it. You only care about what my code does so you can achieve your why.
-
If we are working on the same code we have different whys but the same what. Then your comment as to why isn’t the same as mine which makes the comment incorrect.
-
We are looking at a piece of code and you want to know how it works, because the stated what is wrong (bugs). This might be the “why” you are looking for, but I call this a “how”. This is the case where self documenting code is most important. Code should tell a second programmer how the code achieves the what without needing an additional set of verbose comments. The great thing about code is that it is literally the instructions on the how. The problem is conveying the how to other programmers.
There are three kinds of how: self evident, complex how’s requiring multiple levels of abstraction and lots of code and complex short how’s that are not apparent.
The third is where most people get into trouble. Almost all of these cases of complexity can be solved with only a single layer of abstraction and achieve easily readable self documenting code. The problem for many cases is that they start as a one off and people are lousy at putting in the work on a one-off solution. Sometimes the added work of abstraction, and building a performant abstraction, makes a small task a large one. In these cases comments can make sense.
Sometimes these short, complex how’s require specialists. Database queries, performant perl/functional queries, algorithmic operations, complex compile time optimized templates (or other language specific optimizations) and the like are some of the most common examples of these. This category of problem benefits most from a well defined interface with examples for use (which might be comments). The “how” of these are not as valuable for the average developer and often require specialist knowledge regardless of comments for understanding how they work. In these cases what they do is far more valuable than how or why.
You’ve given a lot of consideration to modern recently created code. But the best modern recent code goes on to become someone’s legacy nightmare. (The most fit and correct code survives long after anyone really wishes it would.)
In high quality legacy nightmare code “why” is lost, unless someone wrote it down.
I’ve been on both sides of that mystery. “Why didn’t they just do X?”
- Sometimes it was because X didn’t exist yet, or wasn’t matute enough.
- Sometimes it was because X is fundamentally the wrong solution, in a very subtle way.
There’s two ways to know the difference:
-
- Painful trial and error.
-
- A comment (or document) answering “why”.
I prefer the second way, but I happily charge more for the first way.
-
Absolutely agree, yeah
This is why code review exists. Writer’s can’t always see what’s wrong with their work, because they have the bias of knowing what was intended. You need a reader to see it with fresh eyes and tell you what parts are confusing.
That’s not to say you shouldn’t try to make it readable in the first place. But reviewing and reading other people’s code is how you get better.
Most technology, programming languages and frameworks feel just the same, in a professional environment. Majority of web and apps is so simple that literally anything will do. Simple api consumption, simple database crud stuff. The tech stack doesn’t matter that much.
And when it does matter, there’s never a perfect fit.
That ML is just a paradigm and won’t do much of what people believe it eventually will.
My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.
After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.
Amen. I once had an interview where they asked what my skill is with .net on a scale of 1 - 10. I answered 6.5 even though at the time I had been doing it for 7 years. They looked annoyed and said they were looking for someone who was a 10. I countered with nobody is a 10, not them or even the people working on the framework itself. I didn’t pass the interview and I think this question was why.
Did your interviewer profess to be a 10 in .net, otherwise how would they know what that looks like? I was told that I’m unsuitable as a programmer of PLC because I never used their software before. That I write the algorithms that go into a PLC was not sufficient. These people are looking for unicorns but find donkeys everywhere they look.
He claimed everyone at dev II and higher was a 10 in their company. Complete dunning Kruger. I have no doubt I could’ve understood and worked on whatever software they have.
As a hiring manager, I can understand why you didn’t get the job. I agree that it’s not a “good” question, sure, but when you’re hiring for a job where the demand is high because a lot is on the line, the last thing you’re going to do is hire someone who says their skills are “6.5/10” after almost a decade of experience. They wanted to hear how confident you were in your ability to solve problems with .NET. They didn’t want to hear “aCtUaLlY, nO oNe Is PeRfEcT.” They likely hired the person who said “gee, I feel like my skills are 10/10 after all these years of experience of problem solving. So far there hasn’t been a problem I couldn’t solve with .NET!” That gives the hiring manager way more confidence than something along the lines of “6.5/10 after almost a decade, but hire me because no one is perfect.” (I am over simplifying what you said, because this is potentially how they remembered you.)
Unfortunately, interviews for developer jobs can be a bit of a crap shoot.
They wanted to hear how confident you were in your ability to solve problems with .NET. They didn’t want to hear “aCtUaLlY, nO oNe Is PeRfEcT.”
Yeah, I mean no shit, with hindsight it’s obvious they were looking for the 10/10 answer. I was kicking myself for days afterwards because that’s the only question I felt I answered “wrong”. Tech interviews are such a shit show though that you can start to overthink things as an interviewee. Also, an important aspect of the question that I didn’t mention was they specified “1 is completely new, and 10 is working at Microsoft on the .net framework itself”. The question caught me off guard. I have literally no idea what working at Microsoft on the framework is like. In that context being a 10/10 felt like being among the most knowledgeable person of c# of all time. Could I work on the framework itself? Idk maybe, I’ve never thought about it, I don’t even know what their day to day is. I should’ve just said 10/10 though, it was a dev II position to work on a web app, it wouldn’t have been that hard.
10 is working at Microsoft on the .net framework itself.
An interesting spin. I like to imagine that you could have answered “10/10,” taken a pause, and declared that you’re leaving the interview early to apply directly to Microsoft to “work on the .net framework itself.” 🤓
dev II position to work on a web app
”we want you to tell us that you’re over qualified for the role”
Your mistake was giving them an answer instead of asking how the scale was setup before giving them a number. Psychologically, by answering first your established that the question was valid as presented and it anchored their expectations as the ones you had to live up to. By questioning it you get to anchor your response to a different point.
Sometimes questions like this can be used to see how effective a person will be in certain lead roles. Recognizing, explaining and disambiguating the trap question is a valuable lead skill in some roles. Not all mind you… And maybe not ones most people would want.
But most likely you dodged a bullet.
I was kicking myself for days afterwards for not doing exactly as you said. I’m not good at these types of interview questions in the moment. Also before that was the tech interview classic of asking a bunch random trivia questions, which I actually nailed. Also this was for dev II position.
I definitely dodged a bullet though. Some months later I got hired at a different company for 30k more.
Hahaha man I feel you
Python is stupid. Using non printable characters as anything other than token separation is just asking for trouble.
Just use a modern editor and you’ll never have this problem
You can work around most issues in any language with the right tools. That’s not the point.
If a design decision introduced a whole new class of errors it is probably just bad design.
deleted by creator
It also greatly improved readability of the language. Since switching to the standard of using 4-space tabs, I’ve not had any problems except when dredging up someone’s old Python 2 code.
You can create some really ugly code in spite of the forced indentation in python. Indentation does not really help here at all. In all languages you can correctly or incorrectly format things. A code formatter strictly applying a coding standard helps far more here than indents vs bracers. Take a look at black it takes the pep8 standards and adds more strict things on top making code look a lot more consistent and thus makes it easier to read.
And all formatters will indent code consistently, so having it as part of the language parser does not really help improve readability at all. And even without a formatter everyone I know will still correctly indent their code no matter the language used. But sometimes forcing new lines to have a meaning does make things worst - just look at pythons lambdas which have to be a single line.
Indentations does not really help readability that much in case of really, really, long code, and in some cases, a code can execute without with unexpected result because of one single indentation being off. Both of these why I like things like curly braces/brackets and terminators like endif/fi/done/end/etc. But, at the end of the day, if there’s a readability problem, then that’s a sign that the code needs to be reworked on.
Oh I think indentation helps a ton with readability. Even for bad, long or otherwise hard to read code - it would be way, way worst with no or wrong indentation. Correct indentation helps a lot. It is not the only thing that can be done to improve readability but it is the first and simplest fix you can apply to a code base. So a language enforcing it with syntax does not matter when even basic text editors can correctly and automatically indent your code.
Though one thing I do like about bracers is I can be lazy with formatting and let my formatter sort it out for me on save. With a white space sensitive language you need to get it correct from the start or else the program just does the wrong thing.
I didn’t say it doesn’t help. But, it alone does not really help for bad and long code, but you are correct in that it would be worse with the wrong indentation. Like you pointed out, the program could do the wrong thing if there is a wrong indentation where indentation matters which is one of my issue with something like Python. And languages with explicit exit scope tend to not have that issue while adding to the benefit of making longer code readable. Where white-space sensitive languages really shine on in my opinion are small codes, and that’s where I think of using Python.
It’s a choice, do you want to deal with brackets or indents? Pick one
Is Haskell, YAML, or Sass also stupid? 🤔
Absolutely yes. JSON and SCSS > YML and SASS
YAML can die in a fire, thanks
Add YAML to that for the same reason.
Actually I did below! You are absolutely correct.
My hot take: Vi, make and C would have gone the way of COBOL a long time ago if it wasn’t for a lot of programmers thinking “my tools are more difficult to use, hence I’m a better programmer”.
Upvoted for make and c, highly disagree on vi/vim though. It’s significantly nicer not having to use a mouse for 95% of my work. Need to delete between two quotations to replace it? v, i, ", d does it. Whole line? d, d. Beginning of end of document? G or gg. There are keyboards to streamline just about any movement or operation, and none involve the mouse. I still need the mouse for clicking stuff in vs code, but that’s mostly just when committing.
Side shout out to emacs, it’s lost popularity over time, but it can do just about anything
For any interested Vi(m) user, one can install evil-mode to get vi keybindings in GNU Emacs.
But why?
Emacs editor commands are kind of clunky, you hold Ctrl or alt a lot and the movement commands are less intuitive and smooth than vi/vim keyboards imo. I’ve heard it described as: emacs has a text editor, vim is a text editor. Vim is great at editing and moving around in documents, selecting and editing text, and basically anything editor based. Emacs can do notes (org mode, linking notes, searching notes, etc), web browser, file browser, git (better git interface than vim), calendar, agenda, music playing, email… and that’s all without plugins
vi lives on because it’s everywhere. On a remote machine and need to edit a file? vi is there.
As a person uses neovim, make and exclusively programs in C I am indeed triggered. Maybe you could argue Make and C are hard but Vi definitely is not (atleast the basics aren’t).
I am triggered by that statement.
I use the unholy IdeaVim and honestly… I love it. I won’t pretend that interacting with a heavy IDE while using vim is a great idea, but it makes editing so much more comfortable.
Also while you can use something like nano for editing files in the terminal, vi(m) is much faster for more in-depth editing.
Vi, make and C are elegant beautiful tools, and the joy they will bring into your life will wait steadfast and pure in spirit until you discover it.
If white space carries any function that the compiler/interpreter needs to know about like structure or scope, it’s probably not a very good programming language.
The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.
Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.
Its ok to have more advanced topic that require more knowledge and that people don’t understand from the first moment they see them.
Abstraction will be the death of traditional software development as we know it
Hot take: people who don’t like code reviews have never been part of a good code review culture.
