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

My guiding principles after 20 years of programming (2020)

alexewerlof.medium.com

Post reply on HN
Print view View original

111–120 of 193 posts

Re: My guiding principles after 20 years of programming (2020)

#111

Post by omginternets »

I like the tech debt quote:

>Tech debt is like fast food. Occasionally it’s acceptable but if you get used to it, it’ll kill the product faster than you think (and in a painful way).

However, I would have worded it more strongly:

>Tech debt is like cocaine. It will make you unnaturally productive, until one day it doesn't.

My point here is twofold:

1. The speed with which which the worm turns is underestimated by Silicon Valley "move fast" culture.

2. The obsession with go-to-market speed in SV and SV-adjacent companies is extreme. In some sense, it's as extreme as the lets-take-blow-and-get-rich finance circles.

There is certainly something to be said for iterating quickly, and it is likewise true that engineers have perfectionist tendencies, but I think our industry has taken a good thing much too far. Going to market has more to do with being focused than with doing sloppy work. Slow is smooth, and smooth is fast.

Re: My guiding principles after 20 years of programming (2020)

#112

Post by fizx »

usrbinbash wrote: post #21

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

This is pretty similar to the "pantsers vs plotters" debate in creative writing. Do you need an outline before writing a novel? How much of one?

Re: My guiding principles after 20 years of programming (2020)

#113

Post by taeric »

omginternets wrote: post #111

I like the tech debt quote: >Tech debt is like fast food. Occasionally it’s acceptable but if you get used to it, it’ll kill the product faster than you think (and in a painful way). However, I would have worded it more strongly: >Tech debt is like cocaine. It will make you unnaturally productive, until one day it doesn't. My point here is twofold: 1. The speed with which which the worm turns is underestimated by Sil…

I think you both oversell it. Debt, as the metaphor, implies borrowed something. You could be borrowing effort from pulled in libraries. You could be borrowing future maintenance time. Both can be valid choices. Both can be success or failure.

So, if you have the time now to not borrow, don't. But if you can leverage growth to have more future resources to pay back on debt, you should probably do so.

Re: My guiding principles after 20 years of programming (2020)

#114

Post by andai »

a9h74j wrote: post #95
andai wrote: post #74

Listing Performance as the lowest value bugs me. I understand that most software isn't performance-critical, you can probably afford to use a garbage collected language for most use-cases. But putting performance last contradicts the high priority of Usability in the list, because Usability strongly depends on performance. Your product might still work if it has a second of lag after every operation, but I won't want…

"Performance serves usability" is, to me, another very strong reason to do at least some prototyping very early.

I don't understand the connection, could you please elaborate?

Re: My guiding principles after 20 years of programming (2020)

#116

Post by usrbinbash »

whynotminot wrote: post #67
blenderdt wrote: post #63

Earlier quoted context omitted.

This is why a good IDE is so important. Since I use Jetbrains products (Rider, PhpStorm) I don't worry about refactoring anymore. This results in a very agile way of working. I believe people underestimate the power of a good IDE.

> I believe people underestimate the power of a good IDE. Definitely. And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. Which, sure, vim is great! And you can get a lot of decent plugins that can make that workable. But gosh IDEs provide so much powerful functionality, why would you make your life harder on purpose by not using them.…

Well, I am a vim user, and I deride noone for the tools they want to use. If someone wants to work in a super-modern IDE, great. If someone wants to work in Notepad++ great. If someone wants to work in ed and use a lineprinter, great. If someone wants to use EMACS, great. Programming is one of the professions, where the craftman gets to choose the tools, and for me, that is something to celebrate.

So with that being said, why do I use vim in a terminal emulator, instead of a modern IDE? Here are my most important reasons. Bear in mind, these are extremely dependent on my personal taste, modus operandi and thinking.

1. Simplicity helps me focus. vim hits a perfect mark between simplicity and feature-richness. Interfacing it with more complex systems such as LSPs, Linters, etc. is almost trivially easy.

2. I like building own tools and adapting existing tools them as I see fit. vim is pretty much perfect in that regard, not just because of the power of vimscript, but because how easily I can integrate tools I wrote myself into it.

3. It's absolutely trivial to set up: I copy my ~/.vim and that's it.

4. Once I figured out jumps, markpoints and linescripts, it allows me to do absolutely crazy things in codebase navigation

5. It works over ssh

6. It runs instantly and has a negligible performance impact

7. I can seamlessly integrate it into other CLI tools that require an editor, providing my default work environment in every situation.

8. Since version 8, I can actually use it as a terminal multiplexer, which is just crazy good for my workflow...I often have several split tabs to edit/navigate the code and a terminal tab controlling deployment and testing on the remote machines...all in a single terminal emulator window.

So yeah, why do I like vim? Because its flexible, fast and extendable, works everywhere and does exactly what I want.

Re: My guiding principles after 20 years of programming (2020)

#117

Post by joseluis »

Palomides wrote: post #108
JKCalhoun wrote: post #94

Earlier quoted context omitted.

Yeah, it could just be me, but I prefer to make two false starts, toss them, and then get it right on the third attempt rather than attempting to whiteboard the problem for two weeks. Not only is it more interesting to me to try three different ways to tackle a problem, but I have been burned when the two weeks of whiteboarding missed something and I'm back to having to iterate anyway. To be sure, I do a little white…

I forget where I read this, but something like: first time to understand the problem second time to understand the solution third time to do it right

it reminds me of some adage for surgeons in training: see one, botch one, nail one.

Re: My guiding principles after 20 years of programming (2020)

#118

Post by stonemetal12 »

ohhnoodont wrote: post #32

> 10. When making decisions about the solution all things equal, go for this priority: Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance In my experience simplicity is the cornerstone priority that nearly all other attributes stem from. Simpler solutions tend to be easier to rationalize/debug, leading to sys…

I guess it depends on what "decisions" we are talking about. I took it to mean design decisions, in which case Security and Simplicity are generally orthogonal.

Plain text passwords are a lot simpler and less secure than salted, hashed passwords. Using bcrypt to hash your passwords is a lot simpler and more secure than some home-grown, self-implemented hashing algorithm.

Also as it says he is talking about priorities, if something is simpler and less secure then choose security. If something is simpler and more secure then hey double win.

Re: My guiding principles after 20 years of programming (2020)

#119

Post by syngrog66 »

fizx wrote: post #112
usrbinbash wrote: post #21

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

This is pretty similar to the "pantsers vs plotters" debate in creative writing. Do you need an outline before writing a novel? How much of one?

both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper

you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been

credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)

Re: My guiding principles after 20 years of programming (2020)

#120

Post by egypturnash »

jcelerier wrote: post #105
paskozdilar wrote: post #78

Earlier quoted context omitted.

> And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. I share the sentiment, but for completely other reasons. Human mind is very limited - it can only hold so much complexity at once before it starts making mistakes and oversights. IDE's raise that bar of tolerable complexity, making it easier for people to build enterprise-level Rube…

> Of course, sometimes we have no choice but to meet the deadline What do you mean, "sometimes"?

There’s a lot of different kinds of deadlines. Some can be extended. Some can not.

“I love deadlines. I love the whooshing noise they make as they go by.” - Douglas Adams, a man who was very familiar with the many varieties of deadlines.

Post reply on HN