Live data from Hacker News

A bunch of programming advice I'd give to myself 15 years ago

mbuffett.com

111–120 of 327 posts

Re: A bunch of programming advice I'd give to myself 15 years ago

#111
post #25

Earlier quoted context omitted.

I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. Who cares about other editors, vi is good enough.

And it's fine. Do what works for you. I just don't think playing with editor endlessly is a well spent time. It makes you feel like you do actual work when you don't. In my opinion.

These days you can write your neovim config in a real language -- lua. I used a pre-defined config called Lazy that does everything vscode can. Then I started tweaking shortcuts, removing and adding plugins, learning more lua.

Then, after I knew what I wanted, I wrote my config from scratch with only the plugins and settings and keybinds I wanted.

It was a very fun process for me. I enjoy simply using my editor. It makes me want to code. I don't get that same level of joy or customization from vscode -- which is phenomenal software btw.

e: replied to the wrong comment in the chain, but the point stands! Customization is how I got into programming. Crafting a status bar on linux, tweaking colorschemes, etc. Don't hate on the tinkerers just because it's not how you enjoy to work. It can be immensely valuable

Re: A bunch of programming advice I'd give to myself 15 years ago

#112

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vsc…

Possibly my all-time favourite XKCD, Is it worth the time?¹, demonstrates two important points. If you only do something very rarely anyway, spending time to automate it won’t have a great ROI. But for things you do moderately often that take a minute or even just a few seconds, you can afford to spend a surprisingly large amount of time optimising them and still get a big pay-off over a time frame measured in years.

I view time spent learning to use my tools efficiently and automating common tasks as a sound investment. Editors are a great example. Sure, I could fire up any of the usual suspects and write code somewhat productively. But in my fully customised editor of choice, I can insert and adapt common code patterns that would take me 10–30 seconds to type out fully in mere moments using templates and macros. I can jump to any position visible on-screen with around three keystrokes. I can see syntax highlighting for various file types that I use all the time, including some unusual ones that don’t have definitions readily available, and warnings for several different programming languages in real time as I work.

These save me a few seconds every time I use them, but how many times is that every day? The effort to set them up has probably repaid itself 100x over by now! And the lack of latency is also a qualitative improvement since it means once I’m ready to start writing, I can do so roughly as fast as I can think, instead of constantly being held back and interrupted for a moment.

¹ https://xkcd.com/1205/

Re: A bunch of programming advice I'd give to myself 15 years ago

#113
post #21

Earlier quoted context omitted.

Maybe add to that: try to stay long enough in a role to really feel the consequences of your actions. Even better if you're on pager for a while too. I know it's not trendy to stay in a job for long these days, and conventional wisdom is it's not great for your salary either, but one thing it will do is allow you to understand whether decisions you made were actually good or not. There are roles I've been in where it…

Skin in the game is important. I have a terrible programmer friend. He is better at creating actual products than most people I met because his livelihood is on the line: he makes money only from websites. So he is not living in the abstract idea of best practices, he had to make it profitable for the last two decades, with little resources to go by on top of that. And he does. After 10 years, he is still asking me h…

Being directly chained to the financial outcome of your works will have you dropping Scrum for Scheme real quick...

Re: A bunch of programming advice I'd give to myself 15 years ago

#114

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. You'll reach the level you want to avoid doing all this. What if future you has reached that level and people on your team are shipping spaghetti?

Then you find a new team, else you can do the classic 'making one trivial hill your Happy Path and be prepared to die on it' routine.

Re: A bunch of programming advice I'd give to myself 15 years ago

#115
post #81
post #36

Earlier quoted context omitted.

A way to rephrase your point about complexity is this wonderful quote " Developers are drawn to complexity like moths to a flame, often with the same outcome " (Neal Ford)

I've experienced this too, but I never understood why this phenomenon happens. Is it because we start adding abstractions before we understand the problems? Like, there's a certain threshold where keep things too simple makes them too complex, so people start introducing abstractions to reduce complexity. But often it's the wrong abstractions and then we accidentally end up with worse complexity that's harder to unra…

It’s because when you’re in the middle of things with a lot of context in your head, adding another little wrinkle feels like a negligible complication (in particular if the new wrinkle is ostensibly to reduce some complexity, or to ship more quickly), but those complications accumulate up to the limits of any developer’s comprehension (and beyond) rather sooner than later. Hence developers tend to work close to the limit of what they can handle in terms of complexity, which for anyone who hasn’t all the same context in their head (like the developers themselves some time later) is really more than they can handle in an effective manner.

From another perspective, this is a form of entropy: There are many more ways to increase complexity than to reduce it. This is also the reason why biological life has been getting more complex over time, the only criterion being if it’s fit to survive and reproduce.

Re: A bunch of programming advice I'd give to myself 15 years ago

#116
post #25

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vsc…

I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. Who cares about other editors, vi is good enough.

> I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying.

I take it that you've learned vim (otherwise you wouldn't be "productive right away" - you wouldn't even know how to input text or save a file) whereas you had apparently never tried vscode before. How can that be a fair comparison?

Re: A bunch of programming advice I'd give to myself 15 years ago

#118

This is interesting. If I were to complement the list, these are some items I’d add that helped me: - learn functional programming. Doing that was how I finally “grokked” programming and could solve problems more easily. Before I was ready to give up. - learn CS history. I studied UX and what I learnt was mostly one side of how to think about computing where you spoon feed users and remove things. There are other way…

"learn fundamentals: data structures, networking, performance, operating systems, security, unix, math. These are so neglected in the industry, and we’re left with super complex systems we don’t actually understand as a result."

I sometimes hold a "command line fundamentals" course for my teams. Just being able to understand the basics puts them above any team that doesn't.

You have to know the ground you're building on. Otherwise even your foundation will be faulty.

Re: A bunch of programming advice I'd give to myself 15 years ago

#119

Earlier quoted context omitted.

Planes and bridges are problems where the quality control can be centralized and you can therefore put a lot of redundancy. Even then, the Boeing scandal shows it's not bulletproof. It's not the same for medicine. There are way more doctors than you can put safety nets. Also, when a plane crashes, it's on the news, it costs money and PR. Much less so with doctors. The plane industry is not inherently more moral, just…

Sure, we're human. There is no argument there. However, normalizing the loss of human life as part of the learning algorithm is psychopathic. There's a time and a place to make mistakes... In mission critical situations that's in training and everywhere else we should aspire for safeguards that prevent the loss of life due to mistakes. In medicine a lot of these deaths can be prevented through greater care. It's not…

I think you're misreading a singular opinion as occurring between two disparate points here.

The initial phrase was > doctors hurt people for years while learning to save them

It's then a separate reply from someone else about deaths from errors/malpractice.

So, nobody seems to be expressing the mentality you are, correctly, lambasting (at least so far as I've read in the comments). But, as it is relevant to the lessons we'd all want to pass back to ourselves (in my opinion, it's because we wish to hold ourselves accountable to said lessons for the future), let's address the elephant in the comment.

Normalising deaths, especially the preventable ones, is absolutely not something that anybody here is suggesting (so far as my read of the situation is).

Normalising responsibility, by recognising that we can cause harm and so do something about it, that seems far more in-line with the above comments.

As you say it yourself, there's a time and a place, which is undoubtedly what we hope to foster for those who are younger or at the start of learning any discipline, beyond programming, medicine, or engineering.

Nobody is saying that the death and loss is acceptable and normalised, but rather that in the real world we need a certain presence around the knowledge that they will occur, to a certain degree, regardless. So, we accept responsibility for what we can prevent, and strive to push the frontier of our capacity further with this in mind. For some, that comes from experience, unfortunately. For others, they can start to grapple with the notion in lieu of it through considering the consequences, and the scale of consequence; as the above comments would be evidence of, at least by implication.

These are not the only ways to develop a mindset of responsibility, fortunately, but that is what they can be, even if you find the literal wording to suggest otherwise. I cannot, of course, attest to the "true" feelings of others, but neither can anyone else... But in the spirit of the matter, consider: Your sense of responsibility, in turn, seems receptive to finding the areas by which such thinking can become justification for the very thing it would otherwise prevent, either as a shield purpose-built for the role or co-opted out of convenience. That too becomes integral, as we will always need to avoid complacency, and so must also promote this vigilance to become a healthy part of the whole for a responsible mindset -- lest we become that which we seek to prevent, and all that.

Exactly as you say, there's a greater problem, but this thinking is not necessarily justification for it, and can indeed become another tool to counter it. More responsibility, more mindfulness about our intents, actions, and consequences? That will prove indispensable for us to actually solve the greater problem, so we must appreciate that different paths will be needed to achieve it, after all, there are many different justifications for that problem which will all need to be robustly refuted and shown for what they are. Doing so won't solve the problem, but is rather one of many steps we will need to take.

Regardless, this mindfulness and vigilance about ourselves, as much as about each other, will be self-promoting through the mutual reinforcement of these qualities. If someone must attempt to visualise the staggering scale of consequence as part of developing this, then so be it. In turn, they will eventually grapple with this vigilance as well, as the responsibility behoves them to, else they may end up taking actions and having consequences that are equivalent to the exact mentality you fear, even if they do/did not actually "intend" to do so. The learning never ends, and the mistakes never will, so we must have awareness of the totality of this truth; even if only as best we can manage within our limited abilities.

Re: A bunch of programming advice I'd give to myself 15 years ago

#120

Earlier quoted context omitted.

Although, I should point out that reading code is not the same as reading tutorials. Reading code occurs with a kind of intent and focus that is missing when you don’t know much, and thus you may end up falling into the trap of studying multiple tutorials without really trying out much yourself.

Tutorials include some code which is intended to be exemplary and simple enough for a new programmer to make sense of, so I wouldn't discount it as a part of reading code. Practical code does not always have those properties, although you'd certainly be missing a lot if you only read code from tutorials. I completely agree with the claim "There is no substitute for doing", and I might even say that code you read with…

Trying to learn to become a developer from tutorials is like trying to become a carpenter by reading instruction manuals for saws, nail guns, &c.

To learn how to implement computer programs, read books about it.

Post reply on HN