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

221–230 of 327 posts

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

#221

Post by throwaway0sa09 »

Chris_Newton wrote: post #112
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…

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 have that XKCD printed out and posted on my cubicle wall. I refer to it quite frequently as justification as to why some requested feature/etc. should NOT be implemented.

I use it so much that many non-technical people at my company have started adopting it as well.

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

#222

Post by 999900000999 »

dan-robertson wrote: post #218
999900000999 wrote: post #158

I'll add one point. You are not your job. Don't take things personally at work. And never be afraid to leave if you're not fitting in with your company . I've left jobs over a few reasons, primarily bad managers, increased compensation, and bad code . If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away . Don't embarrass an…

It’s funny, this comment went in a totally different direction from what I expected based on the start. When you wrote ‘don’t take things personally at work’, I was expecting you to say things things about various kinds of humility – trying to make requested changes in code review instead of pushing back, not feeling wronged if someone rewrites something you wrote, etc – and seeing the bigger picture – the code exist…

I explain more in other comments, but in this situation I was dealing with people who fundamentally could not program .

It wasn't a matter of, oh I would have done this differently, it was more like this company is full of people who have no idea what they're doing and I'd rather not be here .

I will say you should absolutely never talk about code issues at a current employer when interviewing. Who's ever interviewing you is going to interpret this as you being some weirdo who argues over tabs and spaces. There's not enough nuance communicated.

Maybe I'm trying to say you shouldn't take it personally when a company isn't a good fit.

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

#223

Post by kazinator »

seabass-labrax wrote: post #152
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…

The author claims that a strong knowledge of development tools is a good indicator of general proficiency, but what if it's that learning how to use your editor makes you proficient? After all, nobody gets familiar with Emacs without inadvertently becoming a practitioner - if not an enthusiast - of Lisp! That happened with me, and I'm now a big fan of functional programming, Clojure, Scheme etc., and that experience…

> nobody gets familiar with Emacs without inadvertently becoming a practitioner - if not an enthusiast - of Lisp

So you might think, until you meet a fervent Emacs advocate that doesn't know anything about "the underlying Lisp stuff".

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

#224

Post by squeaky-clean »

largelady97 wrote: post #190
austin-cheney wrote: post #176

Earlier quoted context omitted.

Writing ample clear documentation, precision of communication, dutifully fulfilling all timesheets, logging of work performed, attending all requested meetings, and always delivering work on time.

[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 the same equity. Who's the person actually being bent over by the industry here?

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

#225

Post by BobbyJo »

999900000999 wrote: post #204
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.

Or. Hear me out. You're going to then publicly embarrass another co worker. Not a good idea. I need to clarify though, there's a difference between functional code that could have been written better, and code which does nothing at all . I was at a company where three or four people literally were writing code that did nothing but was appearing to function correctly. Imagine an API that checks the status of another s…

> Hear me out. You're going to then publicly embarrass another co worker. Not a good idea

We should all be working with each other under the assumption we are adults capable of receiving feedback. If a coworker is doing poorly, talk to them. If they wont listen escalate. If escalation doesn't work, its a bad fit.

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

#226

Post by zarathustreal »

bazoom42 wrote: post #23

> Assess the trade-off you’re making between quality and pace Very important! But also important to distinguish between kinds of quality. Using a sub-optimal algorithm or bad identifiers or copy-pasted code can always be fixed later. But some problems like a bad database schema is much harder to fix later.

I’d say be very skeptical of this advice if you’re a beginner. You almost certainly aren’t qualified to identify quality so don’t intentionally leave any on the table

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

#227

Post by icedchai »

999900000999 wrote: post #213
icedchai wrote: post #206

Earlier quoted context omitted.

Not necessarily. You can escalate things to your boss. Or then their boss. They talk to the coworker about it. It doesn't have to (and shouldn't be) a public inquisition. Maybe you do some one-on-one sessions / mentoring to try to help them. Maybe you're not patient enough to try this. It's certainly easier to leave most of the time. The code aspect is all shades of gray. I've seen code that "functions" but has such…

I didn't have that experience, I was basically told that I should shut up and get used to working with code that doesn't functionally do anything . Then when I complain later my manager was like, even though the code doesn't do anything it makes our metrics look better. Imagine seeing function1(){ ApiCall("1") } function2(){ ApiCall("2) } Over and over again.

I'd tell them I am not shutting up and this is a major problem affecting the quality of the product. I would then speak to the boss's boss about it and start complaining about the boss doing a poor job, encouraging fake, meaningless metrics to game the system. Maybe they'll get get fed up and tell you to GTFO. Probably not though. The thing about broken organizations is that they take forever to fire anyone, so use that to your advantage while you look for other jobs.

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

#228

Post by jimmaswell »

999900000999 wrote: post #204
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.

Or. Hear me out. You're going to then publicly embarrass another co worker. Not a good idea. I need to clarify though, there's a difference between functional code that could have been written better, and code which does nothing at all . I was at a company where three or four people literally were writing code that did nothing but was appearing to function correctly. Imagine an API that checks the status of another s…

> You're going to then publicly embarrass another co worker. Not a good idea.

Worth it if they really deserve it.

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

#229

Post by 999900000999 »

icedchai wrote: post #227
999900000999 wrote: post #213

Earlier quoted context omitted.

I didn't have that experience, I was basically told that I should shut up and get used to working with code that doesn't functionally do anything . Then when I complain later my manager was like, even though the code doesn't do anything it makes our metrics look better. Imagine seeing function1(){ ApiCall("1") } function2(){ ApiCall("2) } Over and over again.

I'd tell them I am not shutting up and this is a major problem affecting the quality of the product. I would then speak to the boss's boss about it and start complaining about the boss doing a poor job, encouraging fake, meaningless metrics to game the system. Maybe they'll get get fed up and tell you to GTFO. Probably not though. The thing about broken organizations is that they take forever to fire anyone, so use t…

That seems like a whole lot of work, compared to just finding another job and walking out .

I'm not trying to change the world, I'm trying to make money so I can save and retire preferably before I turn 50.

If I've learned anything about life is that you need to pick what battles you want to fight.

If option A is argue with numerous people and openly expose multiple layers of incompetence, to the point where my manager and my coworkers are going to hate me .

Compared to, option B , keeping my head down until I can jump ship and then hoping the next place isn't as bad.

I'm picking B.

You gain nothing by going above and beyond your pay grade.

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

#230

Post by osigurdson »

glouwbug wrote: post #197
999900000999 wrote: post #158

I'll add one point. You are not your job. Don't take things personally at work. And never be afraid to leave if you're not fitting in with your company . I've left jobs over a few reasons, primarily bad managers, increased compensation, and bad code . If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away . Don't embarrass an…

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.
Post reply on HN