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

181–190 of 193 posts

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

#181

Post by is0tope »

renewedrebecca wrote: post #154
is0tope wrote: post #60

Earlier quoted context omitted.

Definitely agree. I think some people find it controversial these days with agile etc but i think making prototypes is a severely underrated skill and practice. Not all problems are obviously tractable from the outset by pure analysis. Sometimes you need to build something out of cardboard and rubber bands (figuratively) to see if it will work. Was a topic I wrote an essay about some time back ( https://www.machow.sk…

The weird danger of making prototypes are managers who think having a prototype means you're almost done with the whole task. This is especially bad when the prototype works, but doesn't work well. They think you just need to polish things up a bit when really, you need to take what you've learned and build the real deliverable.

Yes this is very true. There's a certain amount of managing upward, and expectation setting that is required. Unfortunately a common feature of many companies these days is non-technical management managing technical staff, and in such cases it's indeed a dangerous proposition.

Another example perhaps as to how the software engineering field still has significant maturing to do vs. e.g. mechanical engineering.

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

#182

Post by Falkon1313 »

whynotminot wrote: post #67
blenderdt wrote: post #63

Earlier quoted context omitted.

This is why a good IDE is so important. Since I use Jetbrains products (Rider, PhpStorm) I don't worry about refactoring anymore. This results in a very agile way of working. I believe people underestimate the power of a good IDE.

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

I think that has basis too though. IDEs are huge and hugely complicated. Until fairly recently, they were quite often nearly unusable. Want to edit a text file? You'd first have to start your IDE loading and go to lunch, then maybe if you were lucky by the time you got back it'd be done loading and indexing and you could actually edit your file.

Well not so fast, first you'd have to answer 100 questions to configure the IDE for a 'project'. Only then could you edit your file. Slowly. One. Single. Character. At. A. Time. Waiting for the IDE to become responsive again after each character.

Nowadays, however, the hardware has caught up and some IDEs are actually usable most of the time. And they're indispensable on the big convoluted projects we now deal with, that have tons of dependencies and convoluted ravioli code from OOP hierarchies.

I do kinda miss working on projects that were simple and clean enough to not need an IDE. But it would be terrible to go back to not using one with the code we wrangle these days.

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

#183

Post by epolanski »

> Don’t only write code for the happy scenario.

I always have had problems communicating this to my colleagues, managers and stakeholders.

I remember having this discussion with a stakeholder once when I was a consultant:

PM: "How long would it take to have a page with a table with this payment data and this design?"

Me: "The page you're looking for doesn't exist exactly, it's more complex than that."

PM: "What do you mean?"

Me: "There is a page that maybe, eventually will have this table".

PM: "But I want this"

Me: "Okay, but when the user lands on the page, there is still no data, it is being fetched from our backend service. We need to give the user some feedback and tell him his data is loading".

PM: "Okay, add a spinner or something".

Me: "But that's not enough. What if the server hasn't answered after 5 or 10 or 60 seconds? How would the user react? Should we retry the call? Should we give him some other feedback? What if the response actually contains no data, because for the given filters there are no payments? What if the data is malformed? This may crash the application. What if the user is not authenticated or not authorized for the data? Isn't this an admin-only route? Estimating the table itself is one job, but defining all the requirements and handling all the non-happy-cases or edge cases is a totally different game".

Problem is, explaining this to stakeholders, and sometimes even colleagues that "don't care and just want the task to be over" isn't always simple and the solution is generally "we will fix backend so it sends you always correct data in acceptable times".

And then, you spend much more time fixing these edge cases after you go in prod and it becomes a giant spaghetti ball.

A seasoned and experienced backender very well understands that a (well formed) 200 is just one of possible answers he's gonna give back based on the request and database data, and yet we keep treating the less probable outcome as the only scenario.

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

#184

Post by CRConrad »

bsedlm wrote: post #139
usrbinbash wrote: post #21

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

the 'beautiful' thing about this, is that it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards. In my experience they'd only relucantly agree if and only if it's "do this or die". Which then happens under time-pressure or under stress factors of other kinds. "if it already works, why fix it?" (because it's making developer's live…

> it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards.

> "if it already works, why fix it?"

I suppose one attempt at a fix for this would be to make the user interface of your prototype the least prioritised part; maybe even go out of your way to make it ugly and clumsy, so the thing as a whole looks more like a prototype and less like a "solution".

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

#185

Post by marssaxman »

polishdude20 wrote: post #176
usrbinbash wrote: post #21

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

In a way, coding can be thought of as two distinct things. One: coding is a way to play around with ideas, equivalent to a back of the napkin calculation, a diagram in the sand or a pencil sketch of a part. We use code in this scenario more as a way to write down our thoughts and process. But rather than writing in just pure English and writing an essay or a set of Todos, we write more detailed "specs". "Do this thre…

The same distinction still holds in programming - it's just that the process of using the plan to generate the final product has been automated, by that handy class of tools we call "compilers".

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

#186

Post by anonymoushn »

Falkon1313 wrote: post #182
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.…

I think that has basis too though. IDEs are huge and hugely complicated. Until fairly recently, they were quite often nearly unusable. Want to edit a text file? You'd first have to start your IDE loading and go to lunch, then maybe if you were lucky by the time you got back it'd be done loading and indexing and you could actually edit your file. Well not so fast, first you'd have to answer 100 questions to configure…

Maybe you have to deal with OOP ravioli because the authors were using IDEs.

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

#187

Post by jhgb »

usrbinbash wrote: post #21

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

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

I'd go as far as to say that programming is a good medium for expressing poorly understood and sloppily formulated ideas. Oh, wait, someone else already said that...

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

#188

Post by paskozdilar »

jimmygrapes wrote: post #146
koide wrote: post #38

Earlier quoted context omitted.

The key part here is that you shouldn't be afraid of throwing parts (or even throwing wholes) away. Many times we get too attached to solutions to the wrong problem because that's what we built. So in that sense we could rephrase the idea as do not commit to the code you write until you have a good understanding of the problem. Use it as a learning tool.

Yeah I believe this was identified as the main thing leading to the log4j debacle; they intentionally kept the offending code in there for backwards compatibility and edge cases, which really should have been thrown out a long time ago forcing users to accommodate the update or remain knowingly compromised.

While what you say is true, the context is a little bit different. Java built its whole world on the premise that you write your code once, and you run it everywhere [forever]. Every single breaking change loses you a bit of customers - I suppose Java just cared more about keeping their customers, rather than keeping their customers safe.

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

#189

Post by hnfong »

rablackburn wrote: post #178
alanbernstein wrote: post #75

Earlier quoted context omitted.

Fake progress bar?

Indeed. Or one that doesn’t show progress at all, it just cycles through tips / puns

I propose it's more like showing cat meme pics instead of a progress bar.

(presumably the lift has a "progress bar" equivalent in the form of the level indicator lights)

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

#190

Post by hiepph »

ramesh31 wrote: post #90

I'll add one: Code is permanent. Don't rush it. If it takes you 1.5x the time that it should to complete a feature, that is a million times better than rushing something out that is broken. Even if people are waiting desperately and it's a blocking issue. Take your time, get it right once, and move on.

While living in Italy i learned this idiom "Chi va piano va sano e va lontano". It means "who goes slow and steady wins". It has fundamental impact on my work career. Now I don't rush to learn new tech stack but take things more slowly and immerse myself in it.

"The only way to go far is to go right".

Post reply on HN