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

21–30 of 150 posts

Re: How I became a better programmer (2017)

#21

Post by echelon »

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

> 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 one of anything makes learning the next one easier. Programming languages, spoken languages, musical instruments, sports cars, martial arts, sports, weapons, drawing, etc. Your brain builds a rich scaffold you can hang new concepts from.

Re: How I became a better programmer (2017)

#22

Post by codr7 »

Once you know a handful of different programming languages, write an interpreted language embedded in your preferred host language.

It doesn't have to be fancy, I recommend using Forth or Lisp as a starting point; but write something real, do your thing.

I find that most compilers are toys and replicas of existing languages on top of that, which misses the point of designing your own tool.

https://github.com/codr7/gfoo

Re: How I became a better programmer (2017)

#23

Post by Twisol »

majormajor wrote: post #20
Twisol wrote: post #16

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an under…

> I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this. Bad abstractions and models make it much harder to understand code, though. So for junior devs, yeah, it would often be better to be very, very careful, and think very,…

> Bad abstractions and models make it much harder to understand code, though.

True! The point I'm trying to make is more that code clarity is important and worth striving for, regardless of the means you use to achieve it. Clarity is a non-negotiable part of my definition of "nice". If it's also part of others' idea of "nice" -- especially those of novice developers who look to more experienced developers for guidance -- then this paragraph might suggest that clarity can be down-played. It can't.

If you're an experienced developer, you should be able to find good abstractions for achieving clarity in-context. But novice developers can still identify code that's unclear (to them, especially).

Blindly applying abstractions rarely helps with code clarity. Some developers apply certain abstractions because "it's a best practice", rather than because it's actually more clear. That's definitely not what I'm advocating for.

Re: How I became a better programmer (2017)

#24

Post by Twisol »

Vinnl wrote: post #17
Twisol wrote: post #16

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an under…

...and also: bad abstractions can be major impediments to it.

Clarity is primary; good abstractions allow you to achieve it. The fact that bad abstractions harm clarity is something we agree on very strongly.

Re: How I became a better programmer (2017)

#25

Post by megaframe »

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 routinely write in no less than 4 languages for work... comfortably in all of them. Each certainly have their own nuances but the skills translate and made learning the others easier. At worst I (have had to and do) sometimes look up syntax or end up using a design that's less than optimal for that languadge, but that still works.

Re: How I became a better programmer (2017)

#26

Post by bcrosby95 »

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…

Sure, but it will still be a while before you aren't just writing Python in Rust.

Re: How I became a better programmer (2017)

#27

Post by movedx »

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 least amount of code possible, and skipping optimisations, whilst also providing some value to people who can tell you what direction to go in next. That's a business thing - the business needs something in the market ASAP and it needs feedback ASAP. Without this you'd write your stack for three years and then release to a world that moved on two years ago.

When you learn how a business is run you begin to understand that getting to market with a less than ideal code base is actually desirable and something to embraced. All of sudden you'll come to understand that money burns quickly so you should learn to develop code to get to market and not to be the fastest code it can be (yet, at least.)

I find the best programmers I've worked with are those that can produce something quickly and optimise it later on.

Re: How I became a better programmer (2017)

#28

Post by jghn »

bcrosby95 wrote: post #26
echelon wrote: post #21

Earlier quoted context omitted.

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

Sure, but it will still be a while before you aren't just writing Python in Rust.

However the more languages you know and the more they're spread across different paradigms the shallower the learning curve will be for any language one wants to pick up.

Re: How I became a better programmer (2017)

#30

Post by jaequery »

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

Then I wrote an MVC framework from scratch because I thought others were too heavy (ZF, Symfony, etc). It helped me understand an application development at a deeper level, figuring out the best strategy for code modularization, organization, and performance. It helped me to learn creating something that looks so painlessly easy to use is a pretty difficult task (there will always be something ugly sticking out). It took me on a ride of what happens with extreme level of abstractions breaking up code for each roles and a simpler route much like the Sinatra / Express bootstrap approach.

I've found a new level of respect for those who develops codes at a macro-level (frameworks / libraries). There are lot of thoughts and love been applied to them. DHL (Rails) is up there, as well as John Resig (jQuery). I'll also give a shout out to Sequel (Jeremy Evans) while at it for creating an ORM that is almost perfect. Vue.js (Evan You) also particularly deserves a lot of credit for what he is doing in the front-end world. I like React too, can be fun, but I did not like the whole Redux experience.

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.

Post reply on HN