Live data from Hacker News

How I became a better programmer (2017)

jlongster.com

101–110 of 150 posts

Re: How I became a better programmer (2017)

#101
One thing that helped me a to was to build a system myself and maintain it for a few years. That way you see what areas come back and cause you trouble over and over again.

If I didn't understand a bit of code I wrote a few months ago, it was probably too complex and worth refactoring. As it was my own system, I couldn't blame anyone else's poor design decisions.

I noticed that keeping the logic as close to the database was generally the way to go. Avoiding changing the database schema and making up for it at the application level was basically adding technical debt.

Re: How I became a better programmer (2017)

#102

I've heard so many things about Clojure. I am a CS student with some experience in the most used languages (JS, java, python). Can someone explain in simple cs terms why Clojure is sooo hyped? What can I do with this language that would be harder with other languages? From what I've gathered it's used in data wrangling and manipulation in general but most data-oriented tools are written in Python.

Clojure is my favourite language to work in, although I only had the opportunity to use it professionally for 6 months. It gives me an overwhelming feeling of quality, forethought, and careful design. So does most of its surrounding ecosystem.

I feel a similar way about Python too though.

The hype probably comes mostly from good concurrency tools + immutable data structures, but at least partly it comes from people who really enjoy working in it.

Re: How I became a better programmer (2017)

#103
post #54

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

Depends on the perspective doesn't it? If the software does what it advertises, and gets to market faster than the competition, then by definition it is good software. It's only in our blinkered views that we ignore these considerations.

Re: How I became a better programmer (2017)

#104

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…

I’ve used Redux for years, and tried many different approaches to it. But when I look at Redux Toolkit I don’t see much of what I’ve enjoyed about Redux.

To me, Redux is just a pattern for how to handle immutable updates. Redux itself isn’t even important. Every layer of abstraction over these plain, pure functions and serializable objects just obscure the simplicity of the architecture, in my opinion. Some of the recommendations expressed in the docs are reasonable, but you don’t need a library for that, just the patterns.

In my experience a lot of the confusion beginners have with Redux is because they think it is a framework that will do things for them. In that light, it looks like there is an unnecessarily large number of parts to understand. I think they often miss the fact that there is no magic, just function composition. The clearer that is, the easier it will be to work with the code.

Re: How I became a better programmer (2017)

#105
post #51

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

indeed the default assumption on hacker news is web site, I feel saddened that so much developer time is spent on getting round the limitations of browsers. There are so many constraints on UI in a browser that any discussion seems moot.

Re: How I became a better programmer (2017)

#106
post #88

Your reasoning for learning C is biased (perhaps you don't know it well as you suggested the others to know the basics)! At the end, hardware understands only values. C is a minimal, efficient and readable language which survived for decades although there are hundreds of other programming languages. It remains an active programming language as long as there is a good compiler support.

Many of the complaints I read about C these days often boil down to a lack of understanding, I think you're right to suggest that the author doesn't know it very well. I also suspect that they haven't taken the time to find and read good C code.

Re: How I became a better programmer (2017)

#107
post #41

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…

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…

I agree with your point but I find the dig at programming in PHP devaluating it.

Re: How I became a better programmer (2017)

#108

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.

> only

Depends on the team. If it’s a team of code ninnies that hem and haw over the “correct” way to do something while deadlines are missed, this is bad. Worse even than ugly code.

Balance. There has to be balance.

Re: How I became a better programmer (2017)

#109
post #54

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

But do they ship, while the competitors are fretting over variable names?

Re: How I became a better programmer (2017)

#110

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 stopped worrying about best practices and just do it.

I do this to some degree - I pick and choose my best practises because, quite frankly, some "best practices" are actually bad IMHO ("anti-patterns").

This is sometimes very context-dependent, but I'm now more sceptical of adopting a common practise that I personally haven't seen the benefit of.

e.g. YAGNI:

Maybe the problem isn't YAGNI, but that you keep building useless shit. Rather than assume things aren't needed in general, maybe work on why your predictions on what YGN are so poor.

Sometimes, the stuff I predict I'll need Are needed after all, and I was glad I started early. Projects can live and die on the how perceptive wrt future changes its devs are; this is just a developed skill, no maxims needed.

Post reply on HN