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

121–130 of 193 posts

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

#121

Post by omginternets »

taeric wrote: post #113
omginternets wrote: post #111

I like the tech debt quote: >Tech debt is like fast food. Occasionally it’s acceptable but if you get used to it, it’ll kill the product faster than you think (and in a painful way). However, I would have worded it more strongly: >Tech debt is like cocaine. It will make you unnaturally productive, until one day it doesn't. My point here is twofold: 1. The speed with which which the worm turns is underestimated by Sil…

I think you both oversell it. Debt, as the metaphor, implies borrowed something. You could be borrowing effort from pulled in libraries. You could be borrowing future maintenance time. Both can be valid choices. Both can be success or failure. So, if you have the time now to not borrow, don't. But if you can leverage growth to have more future resources to pay back on debt, you should probably do so.

That's fair. My post is mostly a reaction to the fact that tech debt is rarely (read: never) handled correctly, i.e. as debt to be paid back with interest. It's instead an excuse to burn the candle at both ends.

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

#122

Post by taeric »

omginternets wrote: post #121
taeric wrote: post #113

Earlier quoted context omitted.

I think you both oversell it. Debt, as the metaphor, implies borrowed something. You could be borrowing effort from pulled in libraries. You could be borrowing future maintenance time. Both can be valid choices. Both can be success or failure. So, if you have the time now to not borrow, don't. But if you can leverage growth to have more future resources to pay back on debt, you should probably do so.

That's fair. My post is mostly a reaction to the fact that tech debt is rarely (read: never) handled correctly, i.e. as debt to be paid back with interest. It's instead an excuse to burn the candle at both ends.

I agree with that. I mainly think it is like most metaphors, and largely used to argue whatever position the debater has. Whatever use it may have, is indeed evaporated as both sides of the debate burn away at it.

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

#123

Post by vaylian »

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.

Because it makes sense. Learning should be part of most professions. People attend conferences and workshops. Companies pay for travel, accommodation, participation and other expenses. Giving your employees time to learn something new with a side project is incredibly cost-effective in comparison to external learning opportunities.

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

#124

Post by verinus »

Dave3of5 wrote: post #91
Clubber wrote: post #86

Earlier quoted context omitted.

I can see where he's coming from. I started around the same time he did and from my point of view from my experience, perhaps I can further explain how I see it. >Performance is last ? Code length is more important than performance? That's wrong. Also correctness is not mentioned at all surely that has to be in that list. Depends on the scenario. Early in my career I was maintaining a scheduling DSS. You would enter…

Eeek > our system could do it in about 10 seconds, give or take > user's don't care about the difference between 10 seconds and 1 second They d,o but your boss doesn't. That is until they complain. Happened to me multiple times over the past 16 years. No one cares about Performance until it's too bad then suddenly it a huge problem. I've been in several projects where fixing performance was a rewrite due to this atti…

imho simplicity ist the most important trait.

I have a rule i derive from that: like economy of movement there must be a requirement for every change/code.

when nobody says what is slow, how can I optimize. I would pick simplicity and maintainability every time over some undefined performance. Especially as high performant solutions tend to be rather complicated compared to simple ones...

3rd party libs come at a price that is often overlooked/ignored...

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

#125

Post by slothtrop »

syngrog66 wrote: post #119
fizx wrote: post #112

Earlier quoted context omitted.

This is pretty similar to the "pantsers vs plotters" debate in creative writing. Do you need an outline before writing a novel? How much of one?

both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)

If one ever does forgo an outline (I'm not sure if this is ever done), you'd probably have to revise the entire thing a lot, such that you're imposing an outline anyway.

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

#126

Post by conjectures »

> Avoid overriding, inheritance and implicit smartness as much as possible. Write pure functions.

Amen, preach it from the mountain.

Can't say I agree performance is bottom of the priority pile. As someone who does numerical work semi regularly, performance can radically change the usefulness of software (interactive versus batch for example).

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

#128

Post by foobarian »

usrbinbash wrote: post #116
whynotminot wrote: post #67

Earlier quoted context omitted.

> I believe people underestimate the power of a good IDE. Definitely. And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. Which, sure, vim is great! And you can get a lot of decent plugins that can make that workable. But gosh IDEs provide so much powerful functionality, why would you make your life harder on purpose by not using them.…

Well, I am a vim user, and I deride noone for the tools they want to use. If someone wants to work in a super-modern IDE, great. If someone wants to work in Notepad++ great. If someone wants to work in ed and use a lineprinter, great. If someone wants to use EMACS, great. Programming is one of the professions, where the craftman gets to choose the tools, and for me, that is something to celebrate. So with that being…

> If someone wants to work in ed and use a lineprinter, great.

Sure, as long as it's not on my dime! :-)

vim et al are great and I know skilled users can get very productive in them, but I would not push it as a default environment for incoming developers. The amount of force-multiplying functionality in the stock install of IntelliJ or VSCode is very good.

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

#130

Post by sdfgdf »

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.

No post body was provided.
Post reply on HN