How I became a better programmer (2017) • Hacker News Board

Re: How I became a better programmer (2017)

#51

Post by dahfizz » Wed, Mar 25, 2020, 2:28 AM UTC

JackMorgan wrote: post #44

jaequery wrote: post #30

About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye…

As a recent convert to redux who ended up recreating it from first principals but in a much much clunkier way, I highly recommend anyone writing a UI in 2020 to have a damn good reason to not use react and redux. It's so well designed today. Well worth the time to learn.

> anyone writing a UI in 2020 to have a damn good reason to not use react and redux.

Avoiding JavaScript is all the reason anyone needs. UI =\= website

Re: How I became a better programmer (2017)

#52

Post by gonehome » Wed, Mar 25, 2020, 2:30 AM UTC

xwdv wrote: post #40

I became a better programmer once I committed to mastering Vim. Don’t know why, but the whole struggle of using it changed the way I thought about code and I gained the power to code at the speed of thought.

I think I actually became better when I stopped spending time messing around with tools and environments and focused on just the programming part.

Sane defaults, know the tool and how to use it, but don’t waste time on configuration. When possible choose the standard tool for the job (IntelliJ for me).

It’s still fun to yak shave, mess with things, play with the terminal etc. but at least for me I found that the time spent doing that was the opposite of productive.

Re: How I became a better programmer (2017)

#53

Post by marta_morena_23 » Wed, Mar 25, 2020, 2:59 AM UTC

"Don't spend much time on making your code look nice"...

Well, thanks a lot. You just made your code much harder to read, improve, change and check for correctness. This is actually a self-contradiction. If the code changes often, then its even more important to make it "look nice". This is something that beginner programmers don't get on several levels: Nice code

* can be reviewed more quickly (broadcasting effect)

* can be checked for correctness much more easily

* is pleasant to work with

* can be changed more easily

* can often even compiled into more efficient machine code

The reason why beginners (and this is not about time invested! Many programmers still are beginners after 30 years in the field) think code doesn't need to look nice is mostly because

1. They don't consider that most of the cost of code comes from maintenance. Writing it is really A FRACTION of the time people will spend with your code over time.

2. They don't consider that creating bugs is one of the most expensive parts of software development.

3. They don't consider that code is read far more often than it is being written.

4. They are simply not ABLE to produce good code and doing so would take them a lot of time.

Now giving the advice to not focus on good/nice code is a recipe for staying a beginner for the rest of your life and making every project your work on a nightmare for everyone else involved.

Re: How I became a better programmer (2017)

#54

Post by PeCaN » Wed, Mar 25, 2020, 2:59 AM UTC

Crazyontap wrote: post #32

My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a…

congratulations you write horrible software

Re: How I became a better programmer (2017)

#55

Post by gonzo41 » Wed, Mar 25, 2020, 3:02 AM UTC

readme wrote: post #48

kovac wrote: post #41

Earlier quoted context omitted.

Not to be rude or anything but if you continue down this road productivity might be the only thing going for you and you'll soon realise you are the only one who can work with your code. Substitute software engineering with any other engineering descipline with "I stopped worrying about best practices" and you will be able to see what's wrong with your approach. But then again, if it's php, your domain doesn't requir…

Exactly. I had coworkers like this, and their code was impossible to understand. To make a simple change to it, it would require days of refactoring just to know you weren't going to introduce a bug. It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write.

How old is the software and what's the change that needed. If the software is past it's ROI and changes are happening due to scope creep then days of refactoring isn't refactoring it's just days of dev work against new requirements. It's just happening on an old product.

Management may be willing to spend that time and not be unhappy with what you perceive as time wasted because they have seen greater than expected ROI on the product already so it's not a loss to them.

Re: How I became a better programmer (2017)

#56

Post by kovac » Wed, Mar 25, 2020, 3:03 AM UTC

readme wrote: post #48

kovac wrote: post #41

Earlier quoted context omitted.

Not to be rude or anything but if you continue down this road productivity might be the only thing going for you and you'll soon realise you are the only one who can work with your code. Substitute software engineering with any other engineering descipline with "I stopped worrying about best practices" and you will be able to see what's wrong with your approach. But then again, if it's php, your domain doesn't requir…

Exactly. I had coworkers like this, and their code was impossible to understand. To make a simple change to it, it would require days of refactoring just to know you weren't going to introduce a bug. It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write.

"It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write." This. When someone does this in a hurry or because they didn't know better, it's understandable. But when someone thinks that this style of working is superior, that's a huge problem.

Re: How I became a better programmer (2017)

#57

Post by ratww » Wed, Mar 25, 2020, 3:08 AM UTC

acemarke wrote: post #36

jaequery wrote: post #30

About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye…

> I did not like the whole Redux experience Out of curiosity, anything specific that concerned you? If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns i…

Not OP but: You probably know the answer to your own question, since I'm guessing you made Toolkit to scratch your own itch! :) The "Redux Experience" is a bit overwhelming, boilerplatey, verbose and full of gotchas. Structures are all over the place. IMO that is solved by Toolkit.

The only problem with Toolkit is that it's not Redux. People don't know it yet, and I have to fight to convince people it's good enough. In an ideal world for me you'd be able to deprecate old Redux and just replace it with Toolkit.

Re: How I became a better programmer (2017)

#58

Post by ratww » Wed, Mar 25, 2020, 3:23 AM UTC

einpoklum wrote: post #34

movedx wrote: post #27

Also learn how to run a business. A weird suggestion on the surface but actually very powerful when understood. In short by learning how a business operates, how cash flows and how expensive things are (people, buildings, software, hardware, accountants, lawyers, ...) you'll begin to understand why an MVP is a powerful tool. you'll also appreciate Agile development practices more too. With an MVP you're writing the l…

I've found the ability to produce something quickly is almost orthogonal to being a "good programmer" (unless you define goodness that way.) Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice.

> Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice.

Fred Brooks has a chapter in Mythical Man Month where he mentions different programmers having different roles within "Surgical Software Team" but that never took off.

I wonder if updating that to 2020 would make more sense to have a group of people shipping features full-steam ahead, another reviewing the code for mistakes, and then having other folks refactoring the mess, behind both of them.

I would frankly enjoy being in just one the three positions, any of them, much more than the position I'm currently: having to be all three at the same time.

Re: How I became a better programmer (2017)

#59

Post by DantesKite » Wed, Mar 25, 2020, 3:37 AM UTC

Crazyontap wrote: post #32

My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a…

I like your honesty and the nonlinear path you took. I find my road is similar.

Re: How I became a better programmer (2017)

#60

Post by cryptonector » Wed, Mar 25, 2020, 3:40 AM UTC

> Understand continuations - Continuations are a low-level control flow mechanism.

Excellent advice right there!

> Scheme is the only language to implement them, and while you will never use them in production, they will change how you think about control flow. I wrote a blog post trying to explain them.

Hmm, well, many languages compile to a continuation passing style (CPS) intermediate. And in many languages it is important to understand continuations to understand how they work. For example, laziness in Haskell is essentially all about continuations and continuation passing style.

What is CPS? Anyone who has been in callback hell knows. In CPS a continuation is just the closure you pass to some function that it will call when it's done. In fact, even in C, the act of returning from a function is very much like the act of calling a continuation, except that by unwinding the stack, the magic of Scheme continuations is lost.