181–190 of 215 posts
Earlier quoted context omitted.
> Once the mess becomes a burden, it's a good time to clean up. Definitely the way to go. It's not a problem until it's a problem.
> It's not a problem until it's a problem. I see it as a problem waiting to happen until it happens.
Earlier quoted context omitted.
Amen! Developers spend their first decade learning how to write complex code, and be clever, and compress everything into the fewest and hardest-to-read smallest amount of code possible. Their second decade they learn that simplicity and readability is always better, even if it does require more code. It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the sa…
Sure, but the converse is that when you have a 10k+ LOC project, you can't read that program linearly anymore. I find that sometimes proponents of "straight-forward code" strive for code to be immediately understandable line-by-line, but in big projects, this is not how you navigate a project; you have to create the right modules and abstractions, otherwise you will get lost.
But with a "keep it simple" philosophy the number of lines of actual code never really matters that much, while code where the developers were clever and complex at every opportunity (often just showing off) the code is quicksand and a quagmire every every single line of the way, and is a nightmare.
two things 1) leading commas in SQL 2) RAISE an EXCEPTION or RETURN --no more `else` statements in code SELECT this , that , something FROM table takes a while to get used to
What is the point of selecting specific columns unless some include large text or blob to consume unnecessary IO?
- Reduce uneccessary IO / resource strain, as you said
- Predictability; consuming program receives data in the same order, every time
- If the DBA adds additional columns to the table, it doesn't hose downstream consumer processes
- Easier to debug if some problem does arise.
- Clarity, if you are only using a few columns from a large table. I might just be getting old though ;)
Data should be served in the simplest, most robust manner.
It should be easily consumed by other services, with little extra effort from the programmer.
If you use Select *, you either accept the possibility of it breaking unexpectedly, or have to write logic within the consuming service to deal with that. If the problem can be eliminated by the DB/query itself, it should be.
It's okay to be messy. Treat code mess with the same techniques you would treat RL mess. Sometimes you sweep it under the rug. You can toss it in a closet or attic. You can buy a shelf or box and toss everything in there. You can clean it up seasonally, like set aside a sprint for it. Some kinds of messes are hazardous and absolutely should not be tolerated - this is similar to leaving milk out or trash piling. Many…
If you live by yourself, you can be as messy as you want. It's only a problem if your mess becomes a biohazard for your neighbors that you have to take care of it. Otherwise, if you're happy with your mess, that's fine.
If you live with other people, your mess in the common area becomes their mess. That's a problem if other people do not like your mess. There needs to be agreed upon standard by those living together.
Eventually, the mess will inhibit your ability to work productively regardless of the situation. I guess you can always throw out dirty dishes and buy new ones, but there is a cost to bear.
Making debuggability (transparency) a first-class design criteria. For many (most) systems, there are designs that make perfect sense, but will be hard to debug. When I started designing so that programs could tell me what they are going to do, what they are doing, and why, and so that their state, wherever possible, could be expressed into a structure where I could "see" the wrongness, my development time went way d…
Interesting. Any examples of libraries or papers?
Rather than just make a loop and increment every so often, I made the system output it's "plan" for the user ramp, and a second component execute the ramp plan. We had a bug in the calculation which we were able to see easily by reading the "plan." Without this step, we would have been unsure if it was the calculation of when to add users, or the implementation of adding a user that had a problem.
They're a super cheap way of
1. allowing feature flags
2. injecting credentials in a way the user thinks about exactly once
3. moving workstation-specific details out of your code repository
They're implemented into the core of most every language in existence (especially shell scripts) and you're probably already using them without knowing. They're (get this) _variables_ for tuning to your _environment_.
Sounds like I'm being sarcastic here (eh, maybe a bit) but it never really hit me until I really dug into the concept.
It's okay to be messy. Treat code mess with the same techniques you would treat RL mess. Sometimes you sweep it under the rug. You can toss it in a closet or attic. You can buy a shelf or box and toss everything in there. You can clean it up seasonally, like set aside a sprint for it. Some kinds of messes are hazardous and absolutely should not be tolerated - this is similar to leaving milk out or trash piling. Many…
Wrong. Absolutely wrong analogy. You can't discount people who keep code clean, modular and simple. It's not an easy thing to do unlike cleaning your house. It just takes one's will to clean the house but when it comes to keeping your codebase clean, it's much more than just will. Sound knowledge of software architecture and design principles is required to write and keep your code clean and unfortunately, the number…
Let me put it this way. I've seen no relationship with code purity and a happy client
I can think of 4 things: 1. Not being afraid to look at the code of the libraries that my main project depends on. It's a slow, deliberate process to develop this habit and skill. But more importantly, as you keep doing this, you will develop your own tactics of understanding a library's code and design, in a short amount of time. 2. Not worrying about deadlines all the time. Not a programming technique as such, but…
What would be some fundamentals to practice for a software developer?
You could for example pick something as simple as a HashTable, and implement it from scratch. Then, you could add more complexity to it, like HTs that won't fit in memory, expanding and shrinking HTs efficiently etc.
Or, you could use one of the several practice websites like LeetCode to practice Algorithms/DS problems.
Once you start building a habit, you will also become better at organizing your practice routine and finding out more about what to work on, and where to look for study/practice materials. But mind you, this is a slow process, which you want to build as a habit. There is no end goal here (like cracking Google interview or such), this is a process to get better at the fundamental skills in your field.
Earlier quoted context omitted.
Hi, thank you for writing the book! Great introduction to Go. One thing I was uncomfortable with about TDD is the step to "just write enough to make the test pass". The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to. In a simple app and a few tests you could probably tell, but the larger an application gets, the less you can put effo…
The point of "just writing enough to make the test pass" is to get you to the point where you have working software (proven by the test, even if the code is "bad") This is the _only_ point where you can safely refactor, if your tests are failing how do you know you haven't broken something? So long as you keep things "green" you know you're ok > The danger seems to be when you have to walk away from some code and you…
Earlier quoted context omitted.
It's an open world roguelike in Clojure. It was counter intuitive to me at first, but modifying real-time behavior like rendering is even easier because the feedback loop doesn't involve player interaction.
Game code doesn't need player interaction either to hotreload. See this section of a talk by Bret Victor for some inspiration: https://www.youtube.com/watch?v=PUv66718DII&t=10m42s