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.
this post was submitted on 01 Sep 2023
16 points (100.0% liked)
Programming
17025 readers
216 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
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."
it doesn't matter if you don't know what it does now
If I don't know what it does now my comment of "I have no idea wtf this does" won't help me in 6 months.
However, engineers who rely solely on comments to explain their code, are bad at writing readable code.
Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It's like the assembly of type systems, except it makes your program slower instead of faster.
load more comments
(1 replies)
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.
load more comments
(3 replies)
Python is only good for short programs
Python should not be used for production environments, or anything facing the user directly. You are only inviting pain and suffering.
Python is only good for short programs
Was Python designed with enterprise applications in mind?
It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.
load more comments
(5 replies)
load more comments
(6 replies)
Not sure if these are hot takes:
- Difficult to test == poorly designed
- Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
- Which programming language doesn't matter (within reason), while amount of programming languages matters a lot
I've been wanting to make my applications easier to test. The issue is, I don't know what to test. Often my issues are so trivial I notice them immediately.
What are some examples of common things in, let's say a web server, that could be unit tested?
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.
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”
load more comments
(1 replies)
Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.
Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.
Using dynamic languages is understandable for a lot of language "external" reasons, just that I really feel like there's no good argument for it.
load more comments
(1 replies)
The best codebase I have ever seen and collaborated on was also boring as fuck.
- Small, immutable modules.
- Every new features was coded by extension (the 'o' in S.O.L.I.D)
- All dependencies were resolved by injection.
- All the application life cycle was managed by configurable scopes.
- There was absolutely no boiler plate except for the initial injectors.
- All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
- "Refactoring" was as simple as changing a constructor or a configuration file.
- All the input/output of the modules were configurable streams.
There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you're a newbie, but it was absolutely brain dead to maintain and extend on.
Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I've seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we'd casually make the change while joking about it.
It might sound mythical and bullshity, and it wasn't perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.
That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not "fun", programming like a cowboy and ignoring the tests is a whole lot of fun.
SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.
90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.
Unless your web site needs to work offline (it probably doesn't), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don't need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).
load more comments
(2 replies)
Modern PHP is great and people judging it by PHP 5 (version that's almost 20 years old) are idiots.
Hot take: people who don’t like code reviews have never been part of a good code review culture.
Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).
load more comments
(2 replies)
As an embedded firmware guy for 10ish years:
C can die in a fire. It's "simplicity" hides the emergent complexity by using it as it has nearly no compile time checks for anything and nearly no potential for sensible abstraction. It's like walking on an infinite tight rope in fog while an earth quake is happening.
For completely different reasons: The same is true for C++ but to a far lesser extent.
Go with what works
Error messages should contain the information that caused the error. Your average Microsoft error "error 37253" is worthless to me
Keep functions or methods short. Anything longer than 20 - 50 lines is likely too long
Comment why is happening, not what
PHP is actually a really nice language to work with both for web and command line utils
Don't over engineer, KISS. Keep It Simple Stupid
SOLID is quite okay but sometimes there are solid reasons to break those rules
MVC is a PITA in practice, avoid it when possible
load more comments
(3 replies)
I find that S-expressions are the best syntax for programming languages. And in general infix operators are inferior to either prefix or postfix notation.
Most modern software is way too complex for what it actually does.
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.
view more: next ›