Live data from Hacker News

The Programmer's Brain

manning.com

41–50 of 104 posts

Re: The Programmer's Brain

#41

Earlier quoted context omitted.

I mean, there's a time and a place for speed reading. Part of being good at speed reading is identifying the areas you need to slow down for and pay attention to. Another aspect of writing code is to think about future speed readers. Can your code be skimmed and understood on a cursory level?

The best code is the code that doesn’t need to be read at all. This takes a lot of skill in abstraction. For example code a “user data cache” with lots of user concerns and people will be reading that code a lot. Code a “generic cache” and test the hell out of it and it’ll never need to be read (or rarely) There will need to be code that deals with users but it can interact with the cache so where business logic ends…

Good insight

Re: The Programmer's Brain

#42
post #27
post #18

The most important skills i wish someone had taught me when i was a young developer was how to interact with people in all areas of the organization, and how to deal with the politics. I was (as a young person), strongly against really wanting to know about these aspects, and instead wanted to be purely technical, but in the end that will mean more for your career than anything else, unfortunately.

I agree with this a great deal. I think I had a strange perception of development coming out of school. The job of a developer is to build something useful (valuable) for the company, imo. The barrier to building something useful is rarely the pure techical difficulty, in my experience. It's knowing what to build and coordinating with others. When I left school I was motivated a lot by building something "cool" or in…

well put

Re: The Programmer's Brain

#43
post #18

The most important skills i wish someone had taught me when i was a young developer was how to interact with people in all areas of the organization, and how to deal with the politics. I was (as a young person), strongly against really wanting to know about these aspects, and instead wanted to be purely technical, but in the end that will mean more for your career than anything else, unfortunately.

Ooooh, it's time to suck our own dicks!!!

Re: The Programmer's Brain

#44
post #26

Earlier quoted context omitted.

I used to check on the Packt page where they gave a book away for free daily a few years ago. Out of all of the books most of them were trash. There was a couple of really good ones in there. But all-over my clear impression from the books was that Packt has basically no lower bar whatsoever on quality.

I picked up all the Rust books when I decided to learn Rust a few months back. Fortunately, two were from the library ( the Rust book and the Apress one), while the other I already had thanks to a Humble Bundle deal (the O'Reilly one). The Rust Programming Book is excellent (and also available freely online/via rustup docs --book, but I like to read on paper when I can). The O'Reilly one is a little out of date, but…

I believe they recently updated the O'Reilly Rust book with a new edition so it's not out of date anymore.

Re: The Programmer's Brain

#45
post #21
post #18

The most important skills i wish someone had taught me when i was a young developer was how to interact with people in all areas of the organization, and how to deal with the politics. I was (as a young person), strongly against really wanting to know about these aspects, and instead wanted to be purely technical, but in the end that will mean more for your career than anything else, unfortunately.

It doesn't hurt but I got a great career out of just being a hands-on kind of technical developer. I tried, and mostly succeeded to avoid places where politics play a big role. That said working well with others is important and I also do that well (If I may say so myself ;) ). Politics as in scheming for power are a total turn off for me. Never been interested and not interested in working with others that operate t…

The simplest situation when politics is going to bite you is when your solution competes with a technically inferior plan backed by vindictive and greedy people who see your arguments as an attempt to undermine their careers.

Re: The Programmer's Brain

#47

Interesting that it specifies "speed reading". I think speed reading for code is actually an anti pattern since it is encouraging your biases and guesses instead of actually reading the damn output. If you ever wondered how people ended up programming stochastically and just making random changes I'd say speed reading is part of it

Disagree, I can only speed read. I have dyslexia and I can’t read “normally” I basically read in blocks. My brain does the rest.

Re: The Programmer's Brain

#48
post #18

The most important skills i wish someone had taught me when i was a young developer was how to interact with people in all areas of the organization, and how to deal with the politics. I was (as a young person), strongly against really wanting to know about these aspects, and instead wanted to be purely technical, but in the end that will mean more for your career than anything else, unfortunately.

As a product creator I can say the same about sales. How I wish someone had told me that when it comes to SaaS the 80-20 is 80% focus on sale (traffic, customer feedback, seo, conversions, etc) and 20 percent is actually technical.

And it's not just about money, even OSS projects need a lot of push and support when the "fun" part is done.

Re: The Programmer's Brain

#49

Earlier quoted context omitted.

I mean, there's a time and a place for speed reading. Part of being good at speed reading is identifying the areas you need to slow down for and pay attention to. Another aspect of writing code is to think about future speed readers. Can your code be skimmed and understood on a cursory level?

The best code is the code that doesn’t need to be read at all. This takes a lot of skill in abstraction. For example code a “user data cache” with lots of user concerns and people will be reading that code a lot. Code a “generic cache” and test the hell out of it and it’ll never need to be read (or rarely) There will need to be code that deals with users but it can interact with the cache so where business logic ends…

Of course it will have to be read, what makes you think you can guess what people will have to read? This seems such an anti-pattern, instead of writing readable code that lives inside the domain where its used, you make an unnecessary abstraction. This is exactly how redundant complexity gets made and you wind up with 16 abstraction layers where each is used just once and a completely unreadable mess.

Re: The Programmer's Brain

#50
post #20

Interesting that it specifies "speed reading". I think speed reading for code is actually an anti pattern since it is encouraging your biases and guesses instead of actually reading the damn output. If you ever wondered how people ended up programming stochastically and just making random changes I'd say speed reading is part of it

Given that her research is heavily focused on how people learn how to program, I can't imagine that any recommendations she might have regarding speed reading code would not be informed by her research.

This is not a very sound assumption.

How we learn and the speed at which we read (how we chunk the information together - and how as an author we put together information to be readily chunkable) are very closely tied together.

Edit: hold on! I think i got lost in the double-negatives, and I agree with you. :)

Post reply on HN