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

241–250 of 327 posts

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

#241

Post by magicalhippo »

Anduia wrote: post #165
skydhash wrote: post #139

Earlier quoted context omitted.

It always depends on the team. And by team, I mean the people working on a somewhat independent part of the project (they don’t need to care about the minutia of some other parts). Issue tracking is a tool, but project managers always wants the tool to become the process. And that’s when you got daily standups, story points, epics, and fixed sprints (aka fake deadlines). Use the tool as a tool. As the devs, add issue…

Correct, but JIRA is not SCRUM. Why does the author mention JIRA as a process? Does he find it slow or convoluted compared to other tools? Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process?

> Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process?

Think that must be it. We use JIRA at work. We have very, very simple processes. We create issues, we assign them, we resolve them and they're closed when deployed ok. Minimal fuss.

I also have access to a customer's JIRA. They have like 6-7 steps between starting working on an issue and saying it's deployed in test environment. Another 5-6 to say it's delivered in prod. I saw the flow chart for the steps and it made my head spin.

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

#242

Post by juangacovas »

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, etc). Also it depends on the projects, but just my two cents.

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

#243

Post by YZF »

BiteCode_dev wrote: post #3

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…

I like this but I think all advice suffers from the problem of the people needing it being incapable of using it and the people who are capable of using it already know it.

You learn by doing x time. There's also a place for study, reading, etc. to supplement this.

This is true in software development. It's true in martial arts. It's true in chess. (the 3 things I've invested some effort in progressing in). I've taught martial arts but there's no magic advice I can give people that will instantly take them to the next level, they need to experience and work through things to progress. Having a teacher helps (a lot).

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

#244

Post by eddd-ddde »

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

Earlier quoted context omitted.

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 interviewin…

I agree so much with your arguments.

There's a huge difference between "I don't like your variable name" and "this code is so messed up that any change will have to be manually checked against 20 major features under 20 different cases".

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

#245

Post by underdeserver »

marcusbuffett wrote: post #7
BiteCode_dev wrote: post #3

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…

These seem just as abstract as mine, if not more so, plus at least I provided examples where I could. Feels weird to criticize my post for general advice + examples, then come up with your own general advice without examples. Also this was just an analogy I know, but doctors definitely don’t hurt people for years while trying to save them, very different profession from ours, if anything doctors earlier in their care…

I didn't read this as a criticism of your post, just as another point of view. Your post is more organized and probably thought through, this guy's is an opinion. No need to get defensive.

My experience with doctors, of which there has unfortunately been plenty, is that the older doctors are much better. If I need something delicate done I want a doctor who's 50-65ish. They know what they're doing, they don't screw around, and they've seen enough to know that yes, your case is the common thing they've seen 500 times before, and that this treatment works and that one doesn't.

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

#246

Post by Panzer04 »

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…

Curious why you'd skip low level. Pay? Industry? Knowledge not helpful?

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

#247

Post by feoren »

t-writescode wrote: post #239
feoren wrote: post #236

Earlier quoted context omitted.

Nobody could easily explain why early (1950s - 1970s) fusion reactors were so difficult. It must have been that everyone was stupid and creating their own problems. No one can explain why the Collatz Conjecture is so hard to prove. It must be because everyone is so stupid and is adding incidental complexity to the problem. Why is everyone so stupid? Or, maybe, possibly, that advice is utter bullshit nonsense and some…

A sign of a good educator is to - while it may take a lot of time and a lot of building up of base concepts - enlighten people through plain language the complexities of their topic. Oftentimes, research papers and similar are written for an audience that is already deeply ingrained in their representative topic, such that those first principles aren't discussed anymore, so perhaps that's where you're coming from whe…

"Good educators" are not solving difficult problems, they're teaching about long-standing solutions to long-understood problems. Long-standing solutions to long-understood problems in software engineering are called "packages" or "libraries" and it usually takes a single command to include them. We're talking about building software, not teaching.

The "explain it to a child" comes after decades of humanity's understanding something. Feynman might have been able to explain quantum mechanics to a child, but quantum mechanics was roughly 90 years old at the time. Nobody would have said Michelson and Morley were introducing "incidental complexity" into their experiment because they couldn't explain why the diffraction pattern looked so weird. What are the odds that they're working on an actual difficult problem!? They must be stupid.

You ignored my comment about fusion power and didn't give any examples of someone actually explaining why the Collatz Conjecture is hard. Nobody knows. The first person who deeply understands why the Collatz Conjecture is so hard is going to be the one who solves it. That's what life is like when you're near the edge of humanity's understanding.

> the chances that the thing the proverbial "you" is working on is one of the incredibly difficult things is very unlikely.

On the contrary. Being on the cutting edge of software engineering is incredibly easy. The discipline is (arguably) about 100 years old. The space of problems is unfathomably vast. Software engineering is applicable to literally any other discipline: pick any one and you should immediately find throngs of unsolved (hard) problems around how to apply software approaches to that problem.

And when anyone in the industry solves a specific problem, that specific problem is largely solved forever, for everyone, for free. So if you're not working on a difficult problem, what are you doing? Copy/pasting what someone else did?

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

#248

Post by feoren »

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 your bullshit metrics so you can climb the ladder-of-shit even higher and play your ridiculous game over and over again while sucking the blood out of the work that real employees are doing. Unfortunately you might even be right that that's the optimal strategy for some kind of psycopathic narcissist who only cares about making as much money for as little work as possible. But some people want to do more with their professional life than to become a slimy little worm parasitizing the hard work of others.

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

#249

Post by l0b0 »

mannykannot wrote: post #39

I like this a lot. While those commenters who say it is too advanced for novices have a point, I feel these are still issues worth thinking about - and coming back to - as they learn. The one exception is “Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code.” My experience with bad code is that it does not tell me much; instead, it presents inscrutable and baffling mysteries. From t…

Agreed. "Perfect" code doesn't exist, but good code is written with the understanding that bugs happen, and exposes information at the right level for people to get the feedback they need, when they need it.

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

#250

Post by rowanG077 »

lolinder wrote: post #205
mostlysimilar wrote: post #187

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. Citation needed. Good developers are just as in demand now as they have ever been.

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