161–170 of 289 posts
Earlier quoted context omitted.
It is often impossible to write code the first time anyways, just do it, realize your technical debt, and come back and refactor it when the better abstraction is more obvious (if any).
Ah, but try that in an interview and see what happens.
1. Make it work 2. Make it work fast 3. Make it work well
In that order.
Earlier quoted context omitted.
Absolutely this. Some people think silos are bad, but it absolutely works brilliantly in terms of team cohesion. No stepping on toes. Few arguments because everyone is responsible for their own stuff. No nitpicking over irrelevant style preferences. Pride in ownership, self accountability, thoughtful decision making (mostly). All this leads to good working relationships that come in handy when cross-realm issues aris…
Until someone goes on vacation, their area blows up and everyone else has to panic fix some code that they've never seen before. As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component…
But, absolutely, a lack of peer review, authentic feedback, and general teamwork causes all sorts of issues in so many ways.
I love DoubleContainer: https://github.com/raxod502/TerrariaClone/blob/master/src/Do... which is fortunately only used in a comment here: https://github.com/raxod502/TerrariaClone/blob/9ea04b15add48...
My favorite part is the overloaded print methods: https://github.com/raxod502/TerrariaClone/blob/master/src/Te...
https://github.com/Galleondragon/qb64/blob/master/internal/c...
This makes me miss my early days of programming, where no code was too verbose or horrible to stop me from progressing towards my goal, no matter how misguided I was. Nowadays I'm distracted by the first hint that there might be some better way, and all progress stops. I think I'm just beginning to recognize this, and maybe one of these years I'll learn to recognize when the right abstraction is really important and…
Earlier quoted context omitted.
On their own, % and / are way slower than +, -, *, >. Cycle counts depend on your architecture, you can look them up. That mod is so slow and should be avoided is a kind of folklore based in truth - kind of like function calls being slow - but like everything time-sensitive the mistake lies in not profiling before (manual) optimization. There's an example on SO, I got similar results just now when I replicated it: ht…
> On their own, % and / are way slower than +, -, *, >. And the branch instruction is free??
I wonder how hard it would be to write a program to automatically refactor code like this into something reasonably clean. My intuition thinks it should be difficult but possible... and extremely useful.
There are linters which do a bit of this, but they only cover the lints they have rules for. I'm pretty sure no one has a rule for "all loop indices declared as class members" because no one writing code of this quality has yet used a linter. Many issues in this code-base are not tractable at all for automated repair: how are you going to rework thousands of line long methods into well-factored classes and methods?
Here are some commits where I used it to remove boilerplate from some test cases. The code was written long before MSTest added support for Assert.ThrowsException.
https://github.com/dbremner/PowerCollections/commit/a364a154...
https://github.com/dbremner/PowerCollections/commit/1de2f916...
https://github.com/dbremner/PowerCollections/commit/183e3c7c...
Earlier quoted context omitted.
It is often impossible to write code the first time anyways, just do it, realize your technical debt, and come back and refactor it when the better abstraction is more obvious (if any).
Compression oriented programming - https://mollyrocket.com/casey/stream_0019.html
I think true spaghetti code requires teamwork. I mean that seriously. You need at least 3 people all with different incomplete and incorrect mental models trying to modify the same codebase at the same time.
I disagree. I inherited an app that I'm maintaining that was written by one person over ~12 years. When requirements were added, he just cloned the app and started making the changes so the new app would meet the requirements. Repeat 2 more times, and you get to now, where there are 4 similar but not identical versions of the same code base, with inconsistently applied fixes to various bugs. All 4 still need to work…
Earlier quoted context omitted.
As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. I now favor code that has…
> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you. Joint code ownership produces better code bec…
On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows.
> I don't hire or work with those people anymore. Neither should you.
If you are unable to work with some people by refusing to use a code architecture that would allow you to use them, does that really make you a superior project manager?
Don't get me wrong, different projects call for different processes. You don't code a blog framework in PHP the same way you program an embedded medical device. In some cases it is a bad idea to give free reign to individuals.
I simply notice that when it comes to abstracting your code, team structure and general project context is often more important than the project's function. In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API.
The alternative would have been to fire half the team and make a nicer code in twice the time. Not what I was hired for.