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

My guiding principles after 20 years of programming (2020)

alexewerlof.medium.com

Post reply on HN
Print view View original

11–20 of 193 posts

Re: My guiding principles after 20 years of programming (2020)

#11

Post by codr7 »

showsover wrote: post #3

I don't know how I feel about the insistence of having pet projects and learning something new every day. It feels like a very work-centered approach to life. Unless of course the pet projects happen at work during working hours, but finding a place that allows that is probably a whole different kind of beast.

I don't know about every single day, but I've worked professionally as a software developer since 1998; and I've been writing code for fun outside of work since I got my first computer around 1985.

Work is when someone tells me what to do or where/how to do it, which is why they usually have to pay me obscene amounts to make it happen.

Re: My guiding principles after 20 years of programming (2020)

#12

Post by bennysomething »

i_like_robots wrote: post #10

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…

Readme based development sounds like a great idea!! Thanks.

Re: My guiding principles after 20 years of programming (2020)

#13

Post by thejosh »

i_like_robots wrote: post #10

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…

Internally where I work we use RFCs if we want to propose a new feature/addition, it helps bring others in to skim the doc to find out if there is anything they need to add. It's not too bad, I quite like this

Re: My guiding principles after 20 years of programming (2020)

#14

Post by beardyw »

Taken individually these items are valuable, but I am not sure about these kinds of lists. My own list would have changed each decade of my career. 10 years - idealism, 20 years - compromise, 30 years - realism, etc. It would be good to see a review by the author in 10 years.

Re: My guiding principles after 20 years of programming (2020)

#17

Post by bluetomcat »

i_like_robots wrote: post #10

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…

With big projects spanning across years, the "problem" is often a moving target. Adding new features alters the problem space dynamically. The best you can do as a maintainer is to be mindful of the original problem that the solution was architected for, and extend the thing without crossing certain boundaries and assumptions.

Re: My guiding principles after 20 years of programming (2020)

#18

Post by codebje »

andreime wrote: post #7
kqr wrote: post #6

Earlier quoted context omitted.

Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.

I think it's amazing if one can claim with a straight face people should `absolutely` be paid for pet projects at work.

If we're arguing here that it's a great form of professional development, why would it be a joke to get better at your job, on your job?

Re: My guiding principles after 20 years of programming (2020)

#19

Post by catwell »

i_like_robots wrote: post #10

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…

This point makes literally no sense to me. He says don't start coding before you fully understand the problem, and then he says the way to explore the problem space is coding (the code-test-improve cycle).

By the way I agree with the last part. Sometimes the best way to understand the problem is writing a half-broken solution for it. You just have to be aware that what you're writing probably won't solve the problem, and make sure all the other stakeholders are aware too (that's usually the hardest part).

Re: My guiding principles after 20 years of programming (2020)

#20

Post by mytailorisrich »

showsover wrote: post #3

I don't know how I feel about the insistence of having pet projects and learning something new every day. It feels like a very work-centered approach to life. Unless of course the pet projects happen at work during working hours, but finding a place that allows that is probably a whole different kind of beast.

Once you've settled into a programming job there is actually very little that is new and intellectually challenging. If you don't do anything else you'll become obsolete and atrophied.

To have pet projects is to break out of this daily slow death and to keep learning and being intellectually challenged while keeping up with the industry.

Post reply on HN