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

161–170 of 327 posts

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

#161

Post by farmeroy »

j45 wrote: post #150
farmeroy wrote: post #125

Earlier quoted context omitted.

I've been using neovim pretty much since I began programming. I had some initial setup and have tweaked it once or twice, but it's by no means been a source of sunk time for me. I recently had to switch to VSCode and had a lot of issues learning all the out of the box key bindings and not having the telescope and fuzzy find windows I was used to was a huge productivity loss for me. When I able to jump back to neovim…

I'm reasonably familiar with both and use them for different cases than each other. vscode at least is my text editor in the gui... but consistently growing :) The time getting up to speed on something new shouldn't be used against something else that is already familiar. Now if the new tool (ie., vscode) could import your neovim setup and get you an equivalent, that would be neat. Comparing the sunk cost time for ne…

I guess my point was that, often times people say some tool (or language, or anything) is easier when what they really mean is that they are used to it.

The fact is, you use something because it resonates with you (or its the only resource you have) and then you get good at it, and then everything else becomes a handicap

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

#162

Post by khana »

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…

[dead]

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

#163

Post by andai »

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…

I think this could have been phrased as, err on the side of shipping faster.

i.e. in most cases the cost of bugs is so low that the benefits of a faster feedback loop greatly outweigh the benefits of a more rigorous development process.

(On top of that, the number of defects asymptotically approaches zero with greater effort invested, i.e. diminishing returns.)

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

#164

Post by oblio »

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…

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.

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

#165

Post by Anduia »

skydhash wrote: post #139
Anduia wrote: post #126

Funny how he casually mentions JIRA as a process that slows you down. I get that his team does the issue tracking somewhere else? What does people use that is faster to process both for devs and the PM?

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?

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

#166

Post by bloopernova »

trashburger wrote: post #148
bloopernova wrote: post #118

Earlier quoted context omitted.

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

Could you please share an itinerary for this? I’d also like to hold a similar course but don’t know where to start.

Sure thing! This assumes everyone has macOS, but isn't very mac-specific.

  * Introduction
    Quick history of Unix

  * When you log in
    Difference between login and interactive shells
    System shell files vs user shell files
    .zshenv for environment variables like PATH, EDITOR, and PAGER
    .zprofile for login shells, we don't use it
    .zshrc for interactive shells
    Your login files are scripts, and can have anything in them

  * Moving Around

  ** Where am I?
    pwd = "print working directory"
    stored in variable $PWD
    Confusingly, also called current working directory, so you may see CWD or cwd mentioned

  ** What is here?
    ls
    ls -al
    ls -alt
    . prefix to filenames makes them hidden
    . is also the current directory!
    .. means the parent directory

  ** Finding my way around
    cd
    cd -
    dirs | sed -e $'s/ /\\\n/g'

  ** Getting Help From The Man
    man 1 zshbuiltins
    manpage sections

  ** PATH
    echo $PATH | sed -e $'s/:/\\\n/g'
    zshenv PATH setting

  ** Environment Variables
    env | sort
    EDITOR variable

  ** History
    ctrl-r vs up arrow

  ** Permissions
    Making something executable

  ** Prompts
    zsh promptinit
    zsh prompt -l

  ** Pipes
    Iterate to show how pipes work
    cat ~/.zshrc | grep PATH

  ** Commands

  *** BSD vs GNU commands
    BSD are supplied by Apple, and Apple often uses old versions
    GNU are installed via homebrew, and match those commands available in Linux

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

#167

Post by moonshinefe »

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…

As with most things there's a balance. I've found if I try to learn one or two new features or shortcuts every couple weeks with the tools I use extensively, eventually I do get a sharp axe.

Typing speed is nice but not an important metric I don't think. It's like someone speeding past you on the road only for you to see them at the next red light. Other things will slow you down like code review or needing to wait until a set time to deploy. Also things like copilot and advanced auto-completion are making it less relevant.

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

#168

Post by wruza »

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 really comparable to creating .vimrc from scratch.

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

#169

Post by austin-cheney »

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 the goals.

If you want to be excellent at programming do it as a hobby and set your expectations right that it’s only a hobby.

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

#170

Post by bigdict »

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…

Could you expand a bit on what you mean by administration?
Post reply on HN