Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go ahead, write the “stupid” code

spikepuppet.io

Post reply on HN
Print view View original

91–100 of 157 posts

Re: Go ahead, write the “stupid” code

#91

Post by dgb23 »

I agree but there are certain types of unnecessary stupidity, which feel more easy at at first, but hurt more than they help very quickly (measured in amount of code):

The first one that comes to mind relates closely to naming. If we think about a program in terms of its user facing domain, then we might start to name and structure our data, functions, types too specifically for that domain. But it's almost always better to separate computational, generic data manipulation from domain language.

You only need a _little bit_ more time to move much of the domain specific stuff into your data model. Think of domain language as values rather than field names or types. This makes code easier to work with _very quickly_.

Another stupidity is to default to local state. Moving state up requires a little bit of planning and sometimes refactoring and one has to consider the overall data model in order to understand each part. But it goes a long way, because you don't end up with entangled, implicit coordination. This is very much true for anything UI related. I almost never regret doing this, but I have regretted not doing this very often.

A third thing that is unnecessarily stupid is to spread around logic. Harder to explain, but everyone knows the easy feeling of putting an if statement (or any kind of branching, filtering etc.) that adds a bunch of variables somewhere, where it doesn't belong. If you feel pressed to do this, re-consider whether your data is rich enough (can it express the thing that I need here) and consistent enough.

Re: Go ahead, write the “stupid” code

#92

Post by jstanley »

dgb23 wrote: post #91

I agree but there are certain types of unnecessary stupidity, which feel more easy at at first, but hurt more than they help very quickly (measured in amount of code): The first one that comes to mind relates closely to naming. If we think about a program in terms of its user facing domain, then we might start to name and structure our data, functions, types too specifically for that domain. But it's almost always be…

> we might start to name and structure our data, functions, types too specifically for that domain.

I once worked on a Perl script that had to send an email to "Harry". (Name changed to protect the innocent). I stored Harry's email address in a variable called "$HARRY".

Later on a second person (with a different name) wanted to get the emails as well. No problem, just turn the scalar into an array, "@HARRIES".

I thought it was very funny but nobody else did.

Re: Go ahead, write the “stupid” code

#93

Post by globular-toast »

You should write stupid code, but you should write good code too.

Writing stupid code is like walking to the shop. You're not going to improve your marathon time, but that's not the point. It's just using an existing skill to do something you need to do.

But you should also study and get better at things. If you learnt to cycle you could get to the shop in a third of the time. Similarly, if you learn new languages, paradigms, features etc. you will become a more powerful programmer.

Re: Go ahead, write the “stupid” code

#94

Post by speed_spread »

rtpg wrote: post #35
analog31 wrote: post #21

>>> When I finished school in 2010 (yep, along time ago now), I wanted to go try and make it as a musician. I figured if punk bands could just learn on the job, I could too. But my mum insisted that I needed to do something, just in case. Amusing coincidence. I also wanted to be a rock star, or at least a successful working musician. My mom also talked me out of it. Her argument was: If there's no way to learn it in…

Really still kicking myself for not majoring in robotics in school. I wanted to program, so I studied computer engineering but hadn't really absorbed that much in classes. But I will likely never have access to all the robotics stuff my school had, nor the guided learnings. Never too late to try stuff out of course, but very little beats structured higher ed education in relatively small classes (think there was only…

I worked with robotics engineers, their code and development methods were poor even though software is essential. You need both sides.

Re: Go ahead, write the “stupid” code

#96

Post by katrotz »

withinboredom wrote: post #84
tacitusarc wrote: post #55

Earlier quoted context omitted.

I think this is mostly true, but also I’d highlight the necessity of having a mental model, and iterating. I think it is common for a programmer to just start programming without coming up with any model, and just try to solve the problem by adding code on top of code. There are also many programmers who go with their first “working” implementation, and never iterate. These days, I think the pendulum has swung too fa…

My philosophy: 1. Get it working. 2. Get it working well. 3. Get it working fast. This puts the "just get it working" as the first priority. Don't care about quality, just make it. Then, and only once you have something working, do you care about quality first. This is about getting the code into something reasonable that would pass a review (e.g., architectually sound). Finally, do an optimization pass. This is the…

Slight variation: - Make it work - Make it right - Make it fast

Re: Go ahead, write the “stupid” code

#97

Post by sokoloff »

jasonjmcghee wrote: post #56
amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

Knowing hard requirements up front can be critical to building the right thing. It's scary how many "temporary" things get built in top of and stuck in production. Obviously loose coupling / clear interfaces can help a lot with this. But an easy example is "just build the single player version" (of an application) can be worse than just eating your vegetables. It can be very difficult to tack-on multiplayer, as oppos…

I once retrofitted a computer racing game/sim from single-player to multi-player.

I thought it was a masterpiece of abusing the C pre-processor to ensure that all variables used for player physics, game state, inputs, and position outputs to the graphics pipeline were guarded with macros to ensure as the (overwhelmingly) single-player titles continued to be developed that the code would remain clean for the two titles that we hoped to ship with split-screen support.

All the state was wrapped in ss_access() macros (“split screen access”) and compiled to plain variables for single-player titles, but with the variable name changed so writing plain access code wouldn’t compile.

I was proud of the technical use/abuse of macros. I was not proud that I’d done a lot of work and imposed a tax on the other teams all for a feature that producers wanted but that in the end we never shipped a single split-screen title. One console title was cancelled (Saturn) and one (mine) shipped single-player only (PlayStation).

Re: Go ahead, write the “stupid” code

#98

Post by sfn42 »

jasonjmcghee wrote: post #56
amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

Knowing hard requirements up front can be critical to building the right thing. It's scary how many "temporary" things get built in top of and stuck in production. Obviously loose coupling / clear interfaces can help a lot with this. But an easy example is "just build the single player version" (of an application) can be worse than just eating your vegetables. It can be very difficult to tack-on multiplayer, as oppos…

That's a great point, and I feel like it is relevant for a lot more than games.

We should definitely have a plan before we start, and sketch out the broad strokes both in design and in actual code as a starting point. For smaller things it's fine to just start hacking away, but when we're designing nå entire application i think the right way to approach it is to plan it out and then solve the big problems first. Like multiplayer.

They don't have to be completely solved, it's an iterative process but they should be part of the process from the beginning.

An example from my own work: I took over an app two other developers had started. The plan was to synchronize data from a third party to our own db, but they hadn't done that. They had just used the third party api directly. I don't know why. So when they left and I took over, I ended up deleting/refactoring everything because everything was built around this third party api and there was a whole bunch of problems related to that and how they were just using the third party's data structure directly rather than shaping the data the way we wanted it. The frontend took 30-60+ seconds to load a page because it was making like 7 serialized requests, waiting for a response before sending the next one and the backend did the same thing.

Now it's loading instantly, but it did require that I basically tear out everything they've done and rewrite most of the system from scratch.

Re: Go ahead, write the “stupid” code

#99

Post by sfn42 »

NotGMan wrote: post #80
jasonjmcghee wrote: post #56

Earlier quoted context omitted.

Knowing hard requirements up front can be critical to building the right thing. It's scary how many "temporary" things get built in top of and stuck in production. Obviously loose coupling / clear interfaces can help a lot with this. But an easy example is "just build the single player version" (of an application) can be worse than just eating your vegetables. It can be very difficult to tack-on multiplayer, as oppos…

In many project it's impossible to know the requirements up front, or they are very vagues. Business requirements != programming requirements/features. Very often both the business requirements and programming requirements change a lot since unless you have already written this one thing, in the exact form that you are making it now, you will NEVER get it right the first time.

The problem is people don't adapt properly. If the business requirements change so much that it invalidates your previous work then you need to re-do the work. But in reality people just duct tape a bunch of workarounds together and you end up with a frankensystem that doesn't do anything right.

It is possible to build systems that can adapt to change, by decoupling and avoiding cross cutting concerns etc you can make a lot of big sweeping changes quite easily in a well designed system. It's just that most developers are bad at software development, they make a horrible mess and then they just keep making it worse while blaming deadlines and management etc.

Re: Go ahead, write the “stupid” code

#100

Post by rossant »

amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

I frequently do both. It takes longer but leads to great overall architecture. I write a functional thing from scratch to understand the requirements and constraints. It grows organically and the architecture is bad. Once I understand better the product, I think deeply on a better architecture first before basically rewriting from scratch. I sometimes need several iterations on the most complex products.
Post reply on HN