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

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

mbuffett.com

Post reply on HN
Print view View original

251–260 of 327 posts

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

#251

Post by cess11 »

penteract wrote: post #178
cess11 wrote: post #120

Earlier quoted context omitted.

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.

We might have different ideas about what constitutes a tutorial. Online tutorials vary massively in quality, but something like the official Python tutorial https://docs.python.org/3/tutorial/ is a fine resource. I would even say that the categories are not mutually exclusive - I would call "Structure and Interpretation of Computer Programs" both a book and a tutorial. Different people probably find different resourc…

I wouldn't call it a tutorial. It's the reference manual, but with more words and some stuff about pip and so on to make it more palatable to someone who isn't already initiated.

You need to start by reading somewhere, or you'll probably not get anywhere, as evidenced by pretty much zero office grunts using web browsers every day having figured out the JS console and application development on their own without reading about it. I recommend books over tutorial texts.

But yeah, as I alluded to, you need to build stuff and learn from other builders.

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

#252

Post by gverrilla »

wruza wrote: post #168
trustno2 wrote: post #13

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…

Now I just open vscode with default settings and I am productive right away. I am right away distracted by a huge rectangle around cursor line, current word highlighting and general jumpiness of everything. Coding in vscode feels like writing a book in the middle of brazilian festival. And then it cannot do random simple things like proper indents or humane snippets. The amount of work required to unfuck vscode is re…

I'm a novice. I have only used vscode and sublime. Both have a problem when copying code from elsewhere, where the indent will be wrong every time somehow. If that's what you're talking about, is there an editor that will figure it out correctly somehow? Thanks

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

#253

Post by kortilla »

feoren wrote: post #248
austin-cheney wrote: post #169

The one piece of advice I would give myself 15 years ago: In the corporate world be very good at administration. You only need to just be good enough at programming to not get fired. Everybody has opinions on software techniques and nobody measures anything, so it’s really just a popularity/tool game. The only goals are retain employment or promote out of software, being good at software is just a distraction from th…

I really hate that attitude. It's so self-defeating. The only way to ever advance your career is by becoming a worthless little middle-manager parasite? I'd rather quit. I know that's the common belief: just program long enough that you never have to do it again and then you get a cushy job telling other people what to do and spending hours in worthless meetings coming up with short-sighted "initiatives" to pump up y…

Your attitude towards management is self-defeating too. Good managers make sure people aren’t working on the wrong problems, they clear barriers, and the defend the team from distractions from above.

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

#254

Post by kortilla »

squeaky-clean wrote: post #224
largelady97 wrote: post #190

Earlier quoted context omitted.

[flagged]

All the "10x programmers" I've ever met have been taken advantage of way more and been used as company slaves more than the "clock watchers". I'll "bend over" and be pleasant during a meeting. Then on Friday night I leave work, have a date night with my girlfriend and have to silence Slack because the 10x guy got suckered into working on some odd feature instead of living life. In the end, I get the same salary and t…

You don’t get the same salary and equity as a top performer. Very few companies give flat raises and bonuses without taking into account performance.

And if your manager cares about productivity, the 10x programmer is going to take the cake.

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

#255

Post by nevertoolate »

osigurdson wrote: post #230
glouwbug wrote: post #197

Earlier quoted context omitted.

Do what is asked and go home to your family

That is ok for some but others want to feel like there is some point to the 2/3 of their life that they spent working and preparing to work (i.e. school). For some, punching the clock and collecting a pay check isn't enough.

For me the paycheck isn’t enough so I decided to not to overextend myself at work so I can spend time with family, learning, cooking, etc.

I still have the urge to fight but I also have realized that fighting is more nuanced than pushing all the time. Maybe the best course of action is to push a bit and wait for the next opportunity. Find people you can trust in the org. Play the game. Or sometimes just do like the others, and chill, put in the minimal amount of work.

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

#256

Post by ohthehugemanate »

__turbobrew__ wrote: post #143
hiatus wrote: post #136

Earlier quoted context omitted.

> You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak. I think many would like to probe deeper but aren't afforded the time between sprint tasks. Management often pushes back for solutions that are good enough compared to exploration with an unknown duration until the solution is found.

Part of being senior is figuring out how to work in those constraints. In that situation I would push back my manager and tell them why root causing bugs will save us time in the long run and if they still don’t relent I would sandbag some of my time doing sprint tasks to root cause the bugs.

Which is why it's so important for teams to agree with management on a definition of "done" well in advance, to avoid this kind of argument later. Also why it's important for management to understand that velocity/estimation are Descriptive for long term planning, not Proscriptive and short term.

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

#257

Post by alfiedotwtf »

wruza wrote: post #29

Not sure what 15 years means, but if that’s where I started: (Blasphemies warning) - Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good. - All the money is in the hands of a client. If you’re taking it from someone else, best case you’re taking less than a quarter for essentially the same job. Useless leeches everywhere who perceive y…

This is the first time I’ve ever seen taoup ever recommended besides when I try to bring it up. It’s full of collective knowledge that’s foundational, along with Steven’s books, (if you want to work in Linux land), yet it’s never mentioned :(

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

#258

Post by hereonout2 »

tdumitrescu wrote: post #159
Chris_Newton wrote: post #112

Earlier quoted context omitted.

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…

> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well w…

Absolutely, I try to "automate" or at least have scripted almost everything I do.

I do this almost always for reproducibility and documentation purposes first.

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

#259

Post by nottorp »

juangacovas wrote: post #242
wruza wrote: post #29

Not sure what 15 years means, but if that’s where I started: (Blasphemies warning) - Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good. - All the money is in the hands of a client. If you’re taking it from someone else, best case you’re taking less than a quarter for essentially the same job. Useless leeches everywhere who perceive y…

>Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good. In my personal experience, I think that having to work on different high AND more low level programming languages over time is what sets me apart from people/coworkers with low basic knowledge of computer foundations (the order in my case being Basic, Pascal, C, Perl, C/C++, PHP, JS…

I'd rephrase it as "know both high level and low level and use high level as much as possible".

Knowing the low level will prevent you from shooting yourself in the foot with the high level.

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

#260

Post by nottorp »

tdumitrescu wrote: post #159
Chris_Newton wrote: post #112

Earlier quoted context omitted.

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…

> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well w…

Pasting all the commands in a doc that you keep around seems to give 90% of the benefit of automating it for 1-4 times per year tasks.

It's not typing the commands that takes time, it's remembering what commands to type.

Post reply on HN