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

The Programmer's Brain

manning.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: The Programmer's Brain

#91

Post by badpun »

sbarre wrote: post #76
_hzrk wrote: post #67

Earlier quoted context omitted.

> but in the end that will mean more for your career than anything else, unfortunately. I strongly disagree. In my organisation engineers have higher salaries than "people persons" like managers, product owners etc. Maybe it is something Eastern Europe (Romania) does better. In my country, people become managers when they don't know what to do in life, when they have not mastered any skill in 12 years of mandatory ed…

You know the very common complaint from technical people that goes "my manager/leader doesn't understand what I do"? This is the same thing but from the other side.

Since they live in Romania, it’s very possible that they’re doing outsourced work (for HQ in another country, or even for another company altogether). In such case, the real management happens in HQ, while local managers are just handlers/babysitters like they described.

Re: The Programmer's Brain

#92

Post by jbluepolarbear »

bitexploder wrote: post #74
jbluepolarbear wrote: post #46

I need the version for programmers with extremely bad ADHD.

I have a lot of anecdotes. The thing that tricked my brain was a project I /really/ enjoyed. I could hit flow state working on it pretty often, even as a heavily distracted teenager. This led to me prioritizing a lot of things about software dev in my 20s. Not “follow your passion” but find something really engrossing. It can be hard. But seriously start buying and reading well reviewed book on ADHD, there is so much…

I was being tongue and cheek about it. I know that most programmers will benefit from the material in this book; I teach and train juniors in some of these techniques. I’ve been making games and simulations for 10 years. I’m only able to work on stuff I find interesting. I have a ton of techniques that work for me but they don’t tend to translate to other programmers. I’ve mentored a lot of engineers and I’ve had to learn how “normal” programmers approach problems so that I can guide them and help them when needed. I’m to the point where I’m confident in leading teams and building solid fun games, but I’m still always aware that I am very different from the people I work with. Still to this day the hardest problem for me is taking dozens of concurrent thoughts and converse them in a singular idea. I do not think like that at all; my mind is approaching an idea or problem from ever direction at once. Then technique I use in this case is I speak I a very controlled way (west coast news voice and cadence) this give me time to think about what I’m going to say while I’m currently speaking. It gives me time to judge how what I’m saying is being received and adjust as needed. I’m both writing and refining what I’m saying, this is in tandem with my mind in constant bombardment of thoughts completely unrelated.

Re: The Programmer's Brain

#93

Post by bitexploder »

jbluepolarbear wrote: post #92
bitexploder wrote: post #74

Earlier quoted context omitted.

I have a lot of anecdotes. The thing that tricked my brain was a project I /really/ enjoyed. I could hit flow state working on it pretty often, even as a heavily distracted teenager. This led to me prioritizing a lot of things about software dev in my 20s. Not “follow your passion” but find something really engrossing. It can be hard. But seriously start buying and reading well reviewed book on ADHD, there is so much…

I was being tongue and cheek about it. I know that most programmers will benefit from the material in this book; I teach and train juniors in some of these techniques. I’ve been making games and simulations for 10 years. I’m only able to work on stuff I find interesting. I have a ton of techniques that work for me but they don’t tend to translate to other programmers. I’ve mentored a lot of engineers and I’ve had to…

In my late 20s the stream of unrelated thoughts slowed down some, but it has always been similar for me. I assimilate a lot of surface level things quickly and am always doing a lot of different things... and after several passes and refactorings things start approaching a good state. Amusingly, forcing myself to use tests in places has been very helpful as it helps me back into problems in a more constructive way pretty often. I have always had a very iterative approach to building software. I can definitely make myself work on things now. I don't think I was ever at the extreme end of the ADHD spectrum, but still pretty far along it. I have always struggled to finish things that don't have a deadline of some external factors forcing me to finish them. My periods of productivity are always extremely productive and seem to cover weeks of unproductivity, I have always managed my career pretty successfully. I transitioned to consulting about 15 years ago which was pretty good for me. A lot of different and smaller challenges as opposed to big rocks to move.

Re: The Programmer's Brain

#94

Post by derangedHorse »

nathias wrote: post #72
quickthrower2 wrote: post #64

Earlier quoted context omitted.

The advantage of good abstracting is you can unit test one layer and make it super solid, then build the next layer with less mental load. I am not advocating making “unnecessary” abstractions. I’m not even advocating abstracting from the get go: sometimes you need to see the messy to appreciate the abstracted. This is modulo all common sense trade offs!

Making things into units and making things in generalities is something very different. There is no such thing as a new introduction of a generality that would lessen the mental load in itself, it is both a source of bugs and an obstacle to reading but of course sometimes the tradeoffs are worth it. It just that your solution to reading seems to imply that generalization as such is helpful, and I think its the main c…

I think you're too stuck remembering the bad implementations of generality to understand what the original poster is saying. Something like a cache is general and most likely will need to be used in multiple places. If I have a user cache and an application cache, it wouldn't hurt to build both off a general cache. That way I don't have to understand two different cache implementations that are supposed to do the same thing. Now when a new cache implementation is made in a particular domain, there will be no need to review the code that does the caching since developers should already be familiar from working with it in the past. I don't see how it could be "both a source of bugs and an obstacle to reading" unless done improperly.

Re: The Programmer's Brain

#95

Post by fragmede »

_hzrk wrote: post #67
mbfg wrote: 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.

> but in the end that will mean more for your career than anything else, unfortunately. I strongly disagree. In my organisation engineers have higher salaries than "people persons" like managers, product owners etc. Maybe it is something Eastern Europe (Romania) does better. In my country, people become managers when they don't know what to do in life, when they have not mastered any skill in 12 years of mandatory ed…

> Do you really see yourself the "acting" leader, answering to phone calls all day like a secretary and asking people about the status of their tickets?

You owe it to yourself to find higher quality "people-person"s to learn from. If that's all they're good for in your world, it's no wonder you have such a low opinion of them.

Re: The Programmer's Brain

#96

Post by Graffur »

sbarre wrote: post #76
_hzrk wrote: post #67

Earlier quoted context omitted.

> but in the end that will mean more for your career than anything else, unfortunately. I strongly disagree. In my organisation engineers have higher salaries than "people persons" like managers, product owners etc. Maybe it is something Eastern Europe (Romania) does better. In my country, people become managers when they don't know what to do in life, when they have not mastered any skill in 12 years of mandatory ed…

You know the very common complaint from technical people that goes "my manager/leader doesn't understand what I do"? This is the same thing but from the other side.

You've just taken a good, detailed comment and dismissed it. Do you have anything else to add?

Re: The Programmer's Brain

#97

Post by Graffur »

linklater wrote: post #82
_hzrk wrote: post #67

Earlier quoted context omitted.

> but in the end that will mean more for your career than anything else, unfortunately. I strongly disagree. In my organisation engineers have higher salaries than "people persons" like managers, product owners etc. Maybe it is something Eastern Europe (Romania) does better. In my country, people become managers when they don't know what to do in life, when they have not mastered any skill in 12 years of mandatory ed…

Your livelihood depends on those with people skills. If products don't get marketed, you don't eat. If products don't get sold, you don't eat. If your leader doesn't make the hard and right decisions on where to take the company, you don't eat.

And if the product is bad neither do they. At the end of the day it's all a group effort. Good engineers are not easily replaceable in my experience.

Re: The Programmer's Brain

#98

Post by Graffur »

mbfg wrote: 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 find that people who go down the politics path eventually stop being technical. Some might stay technical but at a very high level and could be able to write code. This may suit some people but for those who want to be software engineers and not managers it's not great advice.

Re: The Programmer's Brain

#99

Post by Graffur »

britch wrote: post #27
mbfg wrote: 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…

Good luck knowing what to build and being able to coordinate with others if you have nobody to actually do the work. Both sets of people are needed. A lot of people in this thread seem to be promoting the non technical side but the technical side is just as important. Look at companies with strong engineering cultures like stripe and Google. You can stay on the technical side.

Re: The Programmer's Brain

#100

Post by sbarre »

Graffur wrote: post #96
sbarre wrote: post #76

Earlier quoted context omitted.

You know the very common complaint from technical people that goes "my manager/leader doesn't understand what I do"? This is the same thing but from the other side.

You've just taken a good, detailed comment and dismissed it. Do you have anything else to add?

While it was detailed, I disagree that it's a good comment, I think it's full of statements I consider to be actually false.

As I said, this is an example of someone forming strong opinions about something they don't really understand.

Since we're all familiar with the trope of non-technical people failing to understand the complexity and intricacies of what we do, it seemed like a good point of comparison.

Post reply on HN