Live data from Hacker News

The Programmer's Brain

manning.com

31–40 of 104 posts

Re: The Programmer's Brain

#31
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.

This. I also wished we learned more about this in my CS degree college classes. Luckily, there is pretty good podcast series that helped me structure team leadership, management and other non technical skills. It is called: Manager tools. Here is the list of all topics on politics [1] with intro to 101 series saying this: "Your organization is MUCH more political than most of us realize. For those who know it's political, some say, I'm not going to play that game. Either state of being - not seeing the politics, or ignoring them, is unfortunate. Professional Life is HUMAN life, and that means it's emotional, and therefore political. Engineers, software designers, technical people take note: hate those marketing and sales people all you want, but they're gonna end up being your boss unless you recognize the value of political, or put differently, non-rational, decision making."

I highly recommend this series at least.

[1] https://www.manager-tools.com/map-universe/politics#

Re: The Programmer's Brain

#32
post #2

are Manning books any better these days? They always used to rush the most awful poorly edited and planned content to market to be the first ones with a book on $NewTechnology

I was to comment the same the other day , but the post was about some book the author was promoting so I didnt want to be a party popper but the book was totally mediocre. It seems to me the inevitable destiny of all "tech" press, start with strong titles and devolve into crap, or to be fairer a crap-shoot. So now you have: ALWAYS HAVE BEEN "CRAP" = Packt and Apress STARTED OK,GOOD NOW MOSTLY CRAP = Pragmatic, Mannin…

I've had mixed results with Packt and Apress (quite a few typos in Packt). Pragmatic, Manning, and No Starch have all been pretty good, as has O'Reilly.

Re: The Programmer's Brain

#33
post #17
post #9

this guy wrote a book that will teach you how to name variables, only with 275 pages!

A cursory look at what I suspect is your GitHub profile reveals you could stand to learn something about good variable naming. Her research focuses on the cognitive processes involved in learning programming and teaching it effectively, which means her audience is likely new/novice programmers. And it's not like one of the oldest jokes about programming doesn't point out how difficult naming things is, which is a sid…

You looked the person up on github to mock their choice of variable naming. How...pathetic.

Re: The Programmer's Brain

#34

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

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 and caching begins is obvious.

Then repeat: how can you split the user code up into generic concepts? Users vs. roles vs. credentials?

Re: The Programmer's Brain

#35
post #21

Earlier quoted context omitted.

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…

"Politics as in scheming for power are a total turn off for me." Most people don't actually scheme for power in an organization. Not directly, anyway. Most people who appear to do that are coming from the perspective of "my (and my team's) needs are the most important here for the business' success"; the purpose isn't actually power, but to get their perceived needs met. Playing politics, then, is being able to under…

> Those few who are just trying to get ahead, without actually advancing the needs of their team are indeed a cancer, and -no one- wants them.

It is a spectrum, not black and white. The person you responded to just have lower tolerance for self serving bullshit.

Re: The Programmer's Brain

#36

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

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

Right, reading twice as fast increases the "WTFs per minute" metric by 4x: 2x because you get through twice as much, and 2x because you understand half as much.

Re: The Programmer's Brain

#37
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.

This sounds like tacit knowledge. You have to experience it to learn. However a buddy or mentor would have been invaluable. Especially one who works elsewhere so there is no fear of reprisal (or talking behind someone’s back) when someone says “my boss was a jerk today”.

The buddy would help you understand if it’s your perspective that needs to change, you need more skills or it really is a shithouse culture and you need to leave. They can also help you understand what career path to take.

I worked somewhere where team leaders got sent to conferences and paid more. Ok looks fun to be a team leader and not a minion. Buddy would say “hang on there….”

Re: The Programmer's Brain

#38
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.

You’re right, I just found the politics inscrutable and so tried to find other ways around it.

Form relationships with people who are good at that sort of thing, who value you for things that you’re good at.

Re: The Programmer's Brain

#39
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.

This. I also wished we learned more about this in my CS degree college classes. Luckily, there is pretty good podcast series that helped me structure team leadership, management and other non technical skills. It is called: Manager tools. Here is the list of all topics on politics [1] with intro to 101 series saying this: "Your organization is MUCH more political than most of us realize. For those who know it's polit…

Seconding the Manager Tools podcast. I used to teach devs coming out of boot camps and half our time was spent on how to manage your manager.

IMO, schools of all kinds need to teach their students how power dynamics are in the real world, how most jobs are about navigating through difficult personalities, and how “being a professional” is not really about winning or losing, but how you play the game.

And look, I get that a good chunk of us would prefer to compartmentalize non-engineering work as much as possible. It’s just that knowing the rules is the best way to decide if you want to engage with them.

Re: The Programmer's Brain

#40

Earlier quoted context omitted.

This. I also wished we learned more about this in my CS degree college classes. Luckily, there is pretty good podcast series that helped me structure team leadership, management and other non technical skills. It is called: Manager tools. Here is the list of all topics on politics [1] with intro to 101 series saying this: "Your organization is MUCH more political than most of us realize. For those who know it's polit…

Seconding the Manager Tools podcast. I used to teach devs coming out of boot camps and half our time was spent on how to manage your manager. IMO, schools of all kinds need to teach their students how power dynamics are in the real world, how most jobs are about navigating through difficult personalities, and how “being a professional” is not really about winning or losing, but how you play the game. And look, I get…

Do you have any resources that you recommend for a dev who's only been in tiny startups (10 people or less)
Post reply on HN