[deleted]
My guiding principles after 20 years of programming (2020)
41–50 of 193 posts
Re: My guiding principles after 20 years of programming (2020)
#42I 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 still (after over 30 years as pro) develop stuff for fun on the site. I don't see that as work (and I don't see my work as work either these days either).
Re: My guiding principles after 20 years of programming (2020)
#43Earlier 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.
Besides the things others have said, some major innovations started as corporate-sponsored pet projects. Gmail is a commonly cited example. I believe many of 3Ms successes (including post-its) also belong to that category.
Re: My guiding principles after 20 years of programming (2020)
#44Earlier quoted context omitted.
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?
To be the devil's advocate, you wouldn't want to pay your plumber for time on his pet project while he's working on your bathroom.
this is such a poor analogy
Re: My guiding principles after 20 years of programming (2020)
#45Earlier quoted context omitted.
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?
To be the devil's advocate, you wouldn't want to pay your plumber for time on his pet project while he's working on your bathroom.
Given the choice, I would absolutely go for the plumber that spends some of their time practising difficult plumbing jobs and doesn't just do routine cases. Even if they are 15 % more expensive. I honestly believe they'll be much better equipped to handle anomalies, should they occur.
Re: My guiding principles after 20 years of programming (2020)
#46> 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.
"Doc > Test > Code" is something I can get behind :)
Re: My guiding principles after 20 years of programming (2020)
#47> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…
If you read ahead two sentences:
> You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end.
So the author seems to agree, somewhat contradicting his own point.
Re: My guiding principles after 20 years of programming (2020)
#48> Any function that’s not pure should be a class. Any code construct that has a different function, should have a different name.
I definitely haven't been following this... anybody else using nearly 99% of functions in their frontend work? (Typically I'm in the React TypeScript world)
Re: My guiding principles after 20 years of programming (2020)
#49> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…
If like most of us you are working on legacy (as opposed to greenfield) then the existing code is a part of the problem space. Coding (and debugging) is a good way to understand that problem!
Re: My guiding principles after 20 years of programming (2020)
#50> Bugs take shelter in complexity. “Magic” is fine in my dependency but not in my code. I disagree with this. Dependencies become your code and any magic will always come and bite you, no matter if it's written by you or a downstream dependency. The guiding principle should be: Reject magic at all cost
I disagree. For a huge majority of projects and teams, it is infeasible to build everything in-house. The way I see it, you can either
1. take an extremely impractical amount of time reinventing the wheel in house, or
2. take a (IMO a relatively much smaller) hit when you fail to take the 10 minutes to read the breaking changes on the dependency. Read this, make fixes, and everything is working again. If you hit a major issue like this with your own tooling, you're at the mercy of your team's ability to quickly build a fix.
A refined version of this point may be something like "only use dependencies which are very well tested, documented, list known issues, and have an active community of development and releases" - don't just install any package or library because "it appears to solve my problem"