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

Re: How I became a better programmer (2017)

#61

Post by jaequery » Wed, Mar 25, 2020, 3:53 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…

Yeah, the toolkit does help a lot actually, I do appreciate you guys for coming up with that. But I wished that it was more like that from day 1. As others have mentioned, it was the "Redux Experience", the sheer verbosity and redundancies that went along with it, for not much gain imo. I'd have liked a lighter abstraction layer.

Re: How I became a better programmer (2017)

#62

Post by hombre_fatal » Wed, Mar 25, 2020, 4:00 AM UTC

dahfizz wrote: post #51

JackMorgan wrote: post #44

Earlier quoted context omitted.

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

The most charitable interpretation of their point is any UI where you were going to use Javascript heavily anyways which is what Redux+Redux competes with.

To take your point to absurdity, you could also just say "nope, write a native client instead."

Re: How I became a better programmer (2017)

#63

Post by acemarke » Wed, Mar 25, 2020, 4:08 AM UTC

ratww wrote: post #57

acemarke wrote: post #36

Earlier quoted context omitted.

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

I'm not sure what you mean by "it's not Redux".

It's still 100% Redux. You create reducers, add them to a store, dispatch actions, and read that data in your components. None of that has changed. You're just writing less code to do it.

What RTK does is eliminate the "incidental complexity" that came along with the original Redux usage patterns: writing action types and action creators by hand, writing complex nested immutable update logic by hand, making a mistake in that immutable update logic and causing accidental mutations, etc [0].

I do understand the suggestion to "replace the Redux core with RTK", and I take it as a great compliment that people suggest that. However, it can't happen, because a lot of people are already using Redux with their own customizations and abstractions. Changing the Redux core to suddenly include a bunch of other dependencies would not be what they want.

The other aspect is that the Redux core was designed from the beginning to be unopinionated, while RTK is _deliberately_ opinionated. Not all Redux users want RTK's opinions. As it is, we've had folks who didn't like the fact that RTK _is_ opinionated and requires use of Immer in our `createReducer` and `createSlice` APIs.

We had a long discussion issue about whether it made sense to add things like this to the Redux core (which was actually part of what prompted us to create RTK in the first place) [1].

FWIW, we explicitly recommend RTK as the standard way to write Redux logic [2], and now that Redux Toolkit 1.3 is out with some new APIs [3], my next task is to create a new "Quick Start" tutorial page for the Redux core docs [4] that does actually teach Redux using RTK as the default syntax, ie, "this _is_ how you write Redux code", in the same way that the Apollo docs teach Apollo-Boost as the default way to use Apollo.

[0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

[1] https://github.com/reduxjs/redux/issues/3321

[2] https://redux.js.org/style-guide/style-guide#use-redux-toolk...

[3] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0

[4] https://github.com/reduxjs/redux/issues/3674

Re: How I became a better programmer (2017)

#64

Post by hombre_fatal » Wed, Mar 25, 2020, 4:10 AM UTC

gonehome wrote: post #52

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…

Like playing an instrument or learning a language, learning Vim/Emacs is something you're glad younger-you did because now you certainly couldn't be bothered.

Then again, these days I just use whatever vim-mode solution there is in VSCode, IntelliJ, etc. and move on. Kind of like how I prefer a GUI for Git these days.

It would blow the mind of my younger self. I just have so many other things going on in my life and on my plate.

Re: How I became a better programmer (2017)

#65

Post by acemarke » Wed, Mar 25, 2020, 4:13 AM UTC

jaequery wrote: post #61

acemarke wrote: post #36

Earlier quoted context omitted.

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

Yeah, the toolkit does help a lot actually, I do appreciate you guys for coming up with that. But I wished that it was more like that from day 1. As others have mentioned, it was the "Redux Experience", the sheer verbosity and redundancies that went along with it, for not much gain imo. I'd have liked a lighter abstraction layer.

Yeah, a number of folks have said "we wish RTK is how Redux always was". I wish that too, but there's no way we (or more specifically Dan and Andrew) could have come up with Redux Toolkit's API at the beginning.

For background, please read my two "Tao of Redux" posts posts [0] [1] to understand why Redux was built this way to begin with. Specifically, it was designed to have a minimal core, and be extensible.

In addition, given the existing Flux library APIs, _and_ that Immer didn't exist, there's no way the Redux Toolkit API would have been feasible at the time. We were only able to come up with it after years of watching how people actually used Redux in practice, and what libraries they were writing on top of Redux to solve specific problems. (People have pointed out that RTK feels kind of like Vuex, which makes sense - Vuex was inspired from Redux's API to begin with.)

Software design is an iterative process. It's based on trying to solve problems, at a specific point in time, with inspiration from existing tools and technologies, and constrained by what is actually available at the time. AngularJS, Backbone, Flux, Redux, Vuex, Immer, NgRx, Redux Toolkit... all of these tools have specific inspirations and problems they were trying to solve. Understanding _why_ tools were created is hugely important.

On that note, my post on "Redux Toolkit 1.0" [2] covers how and why we were able to design RTK's API this way.

[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[2]https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

Re: How I became a better programmer (2017)

#66

Post by arvinsim » Wed, Mar 25, 2020, 4:14 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…

Only works if you are writing for yourself and not with a team.

Re: How I became a better programmer (2017)

#67

Post by kqr » Wed, Mar 25, 2020, 5:05 AM UTC

MaxBarraclough wrote: post #4

kqr wrote: post #3

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only a…

> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it'…

I absolutely agree with you. Being able to call languages fluff comes from me having tried to build real applications with C, Python, Prolog, Erlang, Haskell, Ada, POSIX shell, AWK, Common Lisp, Perl, R, and so on.

Crucially, I don't just think of languages as different syntax for Java.

Re: How I became a better programmer (2017)

#68

Post by kqr » Wed, Mar 25, 2020, 5:08 AM UTC

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 think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple.

I don't fully agree. Yes, some programming needs to be done at a meta level, but far from all of it. Sometimes a software engineer is just there to solve a business problem, and in that case what makes them great is efficiently solving that particular problem, and not a meta-problem.

Sometimes shorter code is easier to write, less buggy, and more maintainable than meta code.

Re: How I became a better programmer (2017)

#69

Post by kqr » Wed, Mar 25, 2020, 5:19 AM UTC

ratww wrote: post #58

einpoklum wrote: post #34

Earlier quoted context omitted.

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

This is an interesting idea. I've frequently found myself in the slow and methodical camp, but I admire the way in which one of the co-founders at my current job can just throw together some amazing proof of concepts in very little time. Of course, the code they write is in general littered with assumptions, missing error handling, and potential performance problems.

I hope I'll be able to learn that part of it too, but perhaps I am more naturally inclined towards writing the second version of their MVP instead.

Re: How I became a better programmer (2017)

#70

Post by kqr » Wed, Mar 25, 2020, 5:23 AM UTC

sp527 wrote: post #45

Doesn’t expound upon two of the most important things: (1) focus on business value over technical challenge (if anything this preaches the opposite) and (2) learn how to get as close as possible to the global optimum in the 3D space formed by time, cost, and quality, depending on the situation.

And (3) read Deming to find out that the 3D space formed by time, cost, and quality does not look like one might think it does – for anything but the quickest of prototypes, increased quality reduces total time and cost!