I write the parentheses before I start writing inside the block. When something goes wrong, the scope of what I’ve done wrong is narrowed to within that specific block.
One of my classes had us design our own 8 bit processor and assembly language. It was a lot of fun designing it. It was like a little puzzle to figure out how to get features into those limitations
Everybody trashing on code reviews has never worked with a shit coder before
I’m a shit coder and almost every single review I’ve made big mistakes like forgetting to delete debug/dead code and there’s always meaningful improvements being suggested
This was my experience too. At first I found code reviews to be an invaluable resource for improving my code. But I then reached a point where I’d learned everything I could from a particular reviewer.
I’d submit code that met every criteria, but the reviewer would still nit pick on tiny details that were entirely subjectective. It was no longer about the quality of code it became about the reviewer trying to put their mark on my work.
The only solution was to either ignore their nits or adopt the hairy arm technique whereby you include intentional errors for the reviewer to comment on so they feel their time had been valuable and you get away without yours being wasted.
I worked with a guy who brought 10k lines of code from various jobs over the years and slapped it all into a single commit second day on the job.
It was all VB.NET and looked like it was written in VB6 days because it was reimplementing functions that the .NET framework already provided us. And there were quite a few single line functions that did the simplest things like addition of two variables.
However my favorite function of all was IsMarksMachine() because it was used as a prod/dev switch. I ran into bugs testing the code and got the “Worked on my machine” line. Turned out the code branch under IsMarksMachine() somehow worked, but in all other cases, it didn’t.
Mark is not the real name. But man was he a bad coder.
That doesn’t mean you are a shit coder, you are just likely forgetful. I also find stupid shit in my committed code, though that is also due to me not caring too much (I guess I really have burned out at my previous work place).
Now I’m at a better job, hopefully I can take proper care of my work here! Hopefully you don’t suffer from burnout.
Agile isn’t that bad. People just believe they are more productive if they are “heads down” and not held accountable for what they write/do.
Functional programming isn’t that great and doesn’t solve all of the world’s problems; it just pushes the issues with state to other parts of your design, and doesn’t scale well in deeply nested solutions.
IDEs with proper code support (i.e. automatic structure analysis, autocomplete, etc.) are one of the best ways to deal with a large codebase that needs refactoring. Doing widescale refactors without one is asking for trouble. If you believe you don’t need it, either your codebase is just that small (which is fine) or playing with fire.
Much of the advice out there on architecture and tooling isn’t properly contextualized on the codebase, market, and team situation. If you believe you have the One True Architecture Solution, you are naive. (Ex. Microservices, large complex code pipelines, monorepos, etc.) Be especially wary of anything from FAANG engineering blogs unless you are also in another letter of FAANG.
There. Got it out of my system. Have fun dissecting it.
The biggest problem with Agile is bad managers fucking it up. But bad managers will fuck things up no matter which way you do things.
But they’re going to want to somehow see progress, and they’ll leave you alone if they see some cards moving on a board. Even if they have no idea what the cards mean.
Whatever, it’s better than having to do status update meetings.
Same , but in my experience this can backfire even worse because the other person thinks you are trying to show off as well as make them look bad. But the problem is less with you and me, and more with this type of person
I really love the project structure of C++. I know ghat it is an archaic design developed like this due to lack of resources, but I find packages extremely offputting.
The first reason is that splitting declaration and implementation across files makes it easier to figure out what something does.
Second reason is that I feel that I have more control over libraries and packages that have to be manuallyaddedto a project rather than using a package manager.
Third, I feel like modern languages iterate over too many versions too fast. C++ has version releases too, but I feel that versioning is handled better from time, compatibility and stability.
Duplicate code can be a code smell, but it’s far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.
Also, some of the deep, highly abstract, functional techniques to reduce duplication are too clever for their own good. Your dev team might worship you as a programming God until someone needs to debug it. Back off on that, even if it means duplicating more code.
This. Especially if your team does not follow SOLID principles (as then someone fixes a bug in a base class method that shouldn’t be shared. This fixes an issue in a subclass but introduces one in another. Rinse, repeat.
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.
You have to learn and conceptualize it. Some things are harder than others to learn and conceptualize. Some tasks can be easily broken down piece by piece, some you can’t do without modeling a complex system in your head. There is definitely a “smartness” scale if only because things have different demands on attention, perception, and short term memory.
Yeah I see what you mean about conceptualization + long term memory. I’ve always felt the process of abstracting things higher and higher to be fulfilling. Not sure why. But, it is very easy to get lost and over engineer and in turn not adding any value besides more stress, solving no real problems.
IMO it isn’t even that it’s necessarily bad, there may very well be a tradeoff that helps you, it’s just that the tradeoff may be different depending on who you are and what your brain can do.
Don’t enforce using the same tech stack on each new project. When customer, domain, environment, requirements etc differ, so might the tool suite, languages, frameworks etc
Good programmers need to be creative, flexible (soft skills with others), critical thinkers, and problem solvers. Lacking those kinds of features makes for a rigid and terrible programmer that is near impossible to work with or code behind. Leave the ego at the door.
Add comment