Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I became a better programmer (2017)

jlongster.com

Post reply on HN
Print view View original

91–100 of 150 posts

Re: How I became a better programmer (2017)

#91

Post by Cthulhu_ »

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…

This is fine as long as you don't stop there; the adage goes "Make it work", which is what you're describing, but don't forget "Make it pretty" and optionally "Make it fast".

Be kind on yourself, your teammates and whoever follows in your footsteps down the line and spend some time tidying up after yourself if you're not building throwaway things as personal projects.

Re: How I became a better programmer (2017)

#92

Post by mattchamb »

chrismcb wrote: post #85
scabarott wrote: post #35

Earlier quoted context omitted.

+1. Add: - Use long expressive variable/function/class names that tell me exactly what this variable/function/class does I have to constantly fight the urge to have code fit in the littlest amount of space possible.

Variable names sound be succinct . They don't need to be short, but they also shouldn't be essays. I had one coworker who would essentially write everything the function did. Variable names would be 100+ chars. It was impossible. Variable names should be as long as needed , but no longer.

I use variable, function and class names as a rough guide on whether I need to refactor. If I name it accurately and the name gets too long, its probably doing too much.

Re: How I became a better programmer (2017)

#93

Post by ivanhoe »

kqr wrote: post #68
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…

I don't see these two as opposed. If you're building a framework that means you need to do some meta thinking about its future users and their needs. If it's a special niche problem then you need some meta thinking about the clients business needs. It's all about deeply understanding the problem that you're attempting to solve.

Re: How I became a better programmer (2017)

#94

Post by jspash »

marta_morena_23 wrote: post #53

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

FYI - the author of the blog post created https://prettier.io/ which is a very opinionated (automatic) javascript code formatter. His assertion about "nice code" was that you shouldn't spend effort on making it look nice. Let a tool do that for you.

Personally I dislike some the default formats that prettier have chosen but if it prevents a single minute of discussion on my team about how the should be formatted, it pays dividends over time. And eventually we, as humans seem to get used to just about anything.

Re: How I became a better programmer (2017)

#95

Post by cjfd »

eskaytwo wrote: post #49
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…

5 times is perhaps a bit high, but many best practices advocate for not abstracting until you re-use the code >3 times, since you may end up adding too many conditionals in to handle all the slight variations. Also - as long as your code is written to be easily readable and refactorable, refactoring can be done when needed. It’s dense complex code that’s too tightly coupled that’s the long-term burden. It’s often abo…

The so-called best practices are wrong sometimes. Or maybe they just talk about generic cases. In which case they often are wrong as well. Having the same code twice can already be highly problematic if it is a longer stretch of code. It is virtually guaranteed that the two places start diverging and then the question is why. Is it because it actually needs to be different? Is it because a bug was fixed in one place that should have been fixed in the other as well but was forgotten?

Re: How I became a better programmer (2017)

#96

Post by cryptica »

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…

For me it's simply the bulkiness of it:

- Babel transpilation aspect (time it takes to build, difficulties associated with ad-hoc debugging in production)

- Bundling/packaging aspect (same reasons as above; time it takes to build, debugging difficulties).

- Huge number of unnecessary dependencies which adds risks/vulnerabilities to projects.

You could argue that it's not React's fault, that it's more about the tooling but I think that it's React's stance on inlining HTML with JavaScript (JSX) which had paved the way for all that bulkiness. From the beginning the project wrongly assumed that:

- Transpilation and bundling doesn't have any costs.

- Dependencies (those needed to do all that fancy transpilation and essentially re-implementing the way the DOM works) don't carry any additional risk and are not a threat to application security, maintenance...

Re: How I became a better programmer (2017)

#98

Post by MaxBarraclough »

echelon wrote: post #21
MaxBarraclough wrote: post #4

Earlier quoted context omitted.

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

> If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming. This is flat out wrong. If you know Python, it'll be easier to learn Rust than having to learn Rust from zero. Engineering is about problem solving and formulating solutions with algorithms and data structures. If you don't know what those are yet, it'll take much longer to learn. Learning…

> If you know Python, it'll be easier to learn Rust than having to learn Rust from zero.

> Learning one of anything makes learning the next one easier

Agreed, but I put easy, not easier. I suspect we really agree on all points.

If you know C#, it's easy to learn Java, as most the concepts are shared, and even the syntax is very similar. When someone says If you learn to program in one language, it's easy to learn another, it betrays that they don't understand that some languages are similar, but some are very different and have unavoidable learning curves.

C++ is a good example. Learning C++ is not easy, no matter what your background knowledge of other concepts and languages. It's a huge language, in which nothing is simple. Even the build model is a minefield. Having a solid understanding of imperative programming and OOP (from knowing Java, say) is certainly an important head-start. I wouldn't recommend C++ as someone's first programming language. There's still an enormous amount to learn about C++ specifically, no matter your background knowledge.

Re: How I became a better programmer (2017)

#99

Post by wccrawford »

marta_morena_23 wrote: post #53

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

While I agree, what they actually said was "if you spend most of your time making your code look pretty", which is obviously too much time, IMO. There needs to be balance.

Re: How I became a better programmer (2017)

#100

Post by superpermutat0r »

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 must agree. If one takes a set of low level practices (like those defined for Spartan programming or something your company likes) and copy pastes that kind of code, it's going to be easy and readable and refactorable.

I have not used OOP or programming patterns or whatever for years and no one got hurt. In various code bases I never used inheritance (abstract classes) or method/dependency injection or whatever someone might ask me in an interview.

The code I copied from elsewhere would just get adapted to the company (Spartan) style and that's it.

Post reply on HN