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

261–270 of 327 posts

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

#261

Post by rldjbpin »

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…

This.

i am much junior but from my experience, working with the toolchain of your team is better in the long run than against it.

if you become proficient quickly with whatever your team works with, it is much better overall than making everyone accommodate you. i have worked in teams where getting neovim installed would confuse the IT as they don't get those requests (or may not even know it exists!).

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

#262

Post by andyjohnson0 »

rowanG077 wrote: post #250
lolinder wrote: post #205

Earlier quoted context omitted.

The demand might be there, but if you have a proven way to get recognized as a "good developer" during the hiring process I'd love to hear it.

References. Ask the good devs you have for someone good they know.

I think the parent commenter was asking from the point of view of a person looking to be employed, not a business or hiring manager looking for devs.

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

#263

Post by dgb23 »

999900000999 wrote: post #238
icedchai wrote: post #231

Earlier quoted context omitted.

I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is. And do you really care if some incompetent hates you? I hate working with incompetent people, so some mutual feelings are perfectly fine. It may even improve the situation, at least temporarily: They'll reduce…

>I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is. Exactly! I do not care about anything in regards to a job outside of my paycheck. I'm not trying to change the world. I have no expectation of anything I'm doing making a real difference.

Honestly your reaction is very understandable. You tried to legitimately improve things, go the extra mile and they treated you badly for it.

But ultimately that’s not how it goes in many places.

There are a lot of people who care more about their craft than their ego. And this can be enriching beyond compensation.

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

#264

Post by tmoertel »

josephg wrote: post #199
icedchai wrote: post #195

Earlier quoted context omitted.

I disagree. If you have problems, you should try to escalate them. It's better for the company... it's better for your coworkers (they're probably also having these problems!) If you escalate them and nothing is changed, then it's time to go. If you're going to leave anyway , you may as well try to change things for the better first.

Yep. I’ve heard this talked about as Voice and Exit . They’re two strategies you almost always have available: essentially, speak up or leave. If all the people who care about a problem leave, it becomes harder for the organisation to solve the problem. This is one form of organisational rot. Most of us are good at one and bad at the other. Eg, my instinctive response has been to quit my job when I’m not enjoying it.…

That model comes from Hirschman's treatise on Exit, Voice, and Loyalty. https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty

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

#265

Post by Chris_Newton »

gverrilla wrote: post #252
wruza wrote: post #168

Earlier quoted context omitted.

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

In Sublime, there is a command to paste while matching the indentation as well. I think it’s Ctrl+Shift+V on most platforms by default. Maybe that’s what you’re looking for?

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

#266

Post by nitely »

dgb23 wrote: post #263
999900000999 wrote: post #238

Earlier quoted context omitted.

>I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is. Exactly! I do not care about anything in regards to a job outside of my paycheck. I'm not trying to change the world. I have no expectation of anything I'm doing making a real difference.

Honestly your reaction is very understandable. You tried to legitimately improve things, go the extra mile and they treated you badly for it. But ultimately that’s not how it goes in many places. There are a lot of people who care more about their craft than their ego. And this can be enriching beyond compensation.

I'll second this. There are a lot of good managers that care more about the product than some team metrics. Same for coworkers that care about improving. Don't let one bad manager define how you'll do things in your next job.

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

#267

Post by Chris_Newton »

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…

I’m a big fan of writing things down for future reference. Keeping a journal with things like exactly which commands I used, or transferring that knowledge to something like a README or a wiki page for others to see, is a low effort but sometimes high reward habit. Even for something done only rarely, saving a lot of time next time can justify the documentation effort.

Similarly, if the automation effort is literally only copying those commands verbatim into a shell script or similar, that’s often time well spent. The trap, as the XKCD helpfully demonstrates, is when you then start spending significantly longer on making that script more “flexible”. Turning hard coded values into parameters. Looking context up from the environment. On multiple development platforms. In staging, UAT and production deployments too. With detailed help text to explain it all and say what the defaults for everything are if you don’t specify them explicitly. And then it turns out that you only actually run that script once every six months anyway and never use 95% of that extra flexibility anyway…

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

#268

Post by Chris_Newton »

darby_nine wrote: post #71
DavidWoof wrote: post #54

Earlier quoted context omitted.

I don't think this point is about configuring your editor/environment as much as just knowing it. There's certain features that come up all the time: find file, find class, go to implementation, find references, rename var, etc. It stuns me how many devs do this stuff manually, when virtually all editors/ides have ways of doing these things.

In some ecosystems, the tooling is just not that good. To use ruby on rails as an example: if you lean into the IDE's expectations for code layout it works ok, but there will always be generated methods and variables with nothing to show but the name—no documentation, no source, no googleable identifier, nothing. In these cases there's nothing to do but pull out the rails (or library) source to try and discern their…

This is a disadvantage of the more dynamic languages, I find. IDEs for languages like C++ and Java are relatively fast and accurate when jumping to definitions, showing references, performing automated refactorings and so on. I rarely see that same precision for any editor or IDE working with TypeScript, Python, and other very dynamic languages, even with the improvements recently thanks to LSP and generally better tools. When almost anything could theoretically have been patched at runtime — even if doing so would be a terrible idea and every style guide says don’t do it — it’s not safe for tools to make the same kind of assumptions with the more dynamic languages that they can with the more static ones.

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

#269

Post by redserk »

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.

US-based individuals here are making 2-3x (or higher!) more cash than the median family (not to mention other comp that easily exceeds a year+ of income of other families)

If 4 years of school and sitting in an air conditioned home office for a few hours a day isn’t rewarding enough on its own, perhaps these folks should pursue perspectives of other people outside of their isolated tech bubble.

I’ll take “bad but meh coworker code” for a life on easy-mode.

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

#270

Post by ransom1538 »

mostlysimilar wrote: post #187
oblio wrote: post #164

Earlier quoted context omitted.

Unless you have a lot of flexibility in terms of where you work, this type of advice is becoming less relevant in an IT job market that's in free fall. Much fewer devs can just jump ship at will than between 2003 - 2022.

> Unless you have a lot of flexibility in terms of where you work, this type of advice is becoming less relevant in an IT job market that's in free fall. > Much fewer devs can just jump ship at will than between 2003 - 2022. Citation needed. Good developers are just as in demand now as they have ever been.

"Good developers are just as in demand now as they have ever been."

Citation needed.

Post reply on HN