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."
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.
From reading the topic overview, that looks great, genuinely good. However, there are about 30 x 25m podcasts, or about 12.5 hours of listening to do. In written form I expect that to be about 2 hours of reading (probably less).
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 interesting. It's part of what got me interested in the field. But it's not the job.
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.
> 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 education + higher education. People who can't code at the end of the CS curriculum have three choices basically: HR, PMO or do a Master in a totally unrelated field to increase your employability. 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? I hope not. A "people person" is easily replaceable, a good engineer is not. When the financial crisis comes and the line is drawn, engineering skills remain. That is not to say that soft skills do not matter, quite the opposite, just don't make it a day job, you will become vulnerable.
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.
> 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.
i'm not suggesting you should switch to a new role that is more of a people person role. I'm saying as an _engineer_, learning how to "politic" is way more important than learning a new language, or having a deep understanding of security, or some other significant technical thing. Not that those aren't good to know, but at some point the "politicing" will be your limiting factor if you can't play the game.
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 that way. Incredibly lucky to be able to pick and choose.
"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 understand those needs, how they interplay and interfere with your own, and how to participate in a way that gets people agreeing on how to move forward, while feeling their needs are met. It is, in fact, exactly what you say of "working well with others". The difference is can you work well with people whose perceptions and needs are completely different than yours (but who are still pushing for what they feel to be the best thing for the company)?
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. Some orgs may not know how to recognize it or to get rid of such people though (or have perverse incentives to encourage such behavior). But their incentive isn't that different; they're still looking to meet their own needs, but it's -their own- needs, rather than that of benefit to the business. I.e., "I want to be perceived as the source of success so that I get promoted, even if that robs my team of recognition" rather than "I want to make sure my team's success is recognized and compensated, so that our morale and performance can stay high, and so the org will trust us with greater responsibility".
We can abstract your statement slightly by saying that it is "scheming to meet a desired objective". Then, in a way you also played "politics" by crafting path in your career to the way you like; in a different way; likely without impacting life of others.
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.
In my 25 years of experience, I've observed that anywhere that a strong purely technical person thrives like that, there's an equally strong manager or leader behind the scenes supporting them, protecting them and clearing a path for them, even if they don't necessarily see it themselves.
That "good fit" you describe is (typically) the existence of that other person.
I don't say this to diminish the talent or accomplishments of that technical person in any way, but in most companies no one succeeds in a vacuum. It's almost always a team effort.
I think HN is a place that is quite focused on fast-growing tech companies and those are often (counter-intuitively perhaps) terrible places when it comes to workplace politics. This is because:
1. The fast growth creates demands for management and "senior dev" positions and since hiring is difficult these positions are often filled from within. This means that those positions will be filled with people who may not be ready for them yet, and who cannot properly control the politics that develop to compensate for that ("Oh person X is difficult? Just ask person Y instead, it'll be fine")
2. The fast advancements (with often come with large monetary rewards) also creates internal competition amongst employees on who will get to be promoted to the newly created position. This can seriously hamstring the company as teams of competing managers subtly sabotage each other.
3. Hiring from the outside is no panacea either, because this means that whoever felt they were "next in line" for a promotion is now faced with a newly minted superior who won't move away themselves in at least the next 18 months or so. This means that, if they want to progress in their career, they need to find another position either in another team within the company or at another company. The first option creates increased internal competition (see point 2), the second option creates increased turnover which costs money and causes loss of institutional knowledge.
4. Finally, just "being a tech company" can give the impression that workplace politics should be absent since "the tech is all that matters". This is untrue, devs are people too and ignoring interpersonal dynamics in favor of technology can be super problematic.
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.
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….”
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.
There is a way out of politics. People hate being seen through. The more of a ‘ok, I see what you are about’ vibe you have going, the more self conscious they become. They often regulate down their politics. Just give people a solid death-stare, and I promise you they adjust.
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?
Speed reading is training your field of view. I would agree that speed reading code is not really useful (even though skimming code looking for interesting stuff is), but what is immensely useful is being able to notice changes on your screen in general. Did something go from green to orange in your IDE? Was there an interesting keyword in the logs flowing by? Did this icon just blink? Has this counter just gone up?
I'm often astonished by the stuff people don't see on their screens when helping them debug something. Replying to "how did you know?!" by pointing to the edge of the screen where some small blob went from green to orange or to red is something that happens more often that I'd expect.
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.
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. :)
>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.
I appreciate that there are other people taking the time to create something like SE-radio, getting interesting individuals on to talk about interesting topics and then giving it away for free (I do not consider it payment to listen to an occasional ad for 10 seconds).
But I have tried so many times to start listening to SE-radio and always given up do to the audio quality. It is so grating when the interviewer and interviewee have drastically different volumes and quality.
This may have been fixed by now, as it has been around two years since I last tried.
Volume levels are relatively easy address so hopefully they have that under control. Quality is hard because you take your guests as they are and people often don't realize the how echoey their room is or how poor the microphone they have is.
I use Izotope de-reverb on my own podcast to improve the quality somewhat, but there is only so much you can do.
I believe she had an intermediate Excel course on either EDX or Coursera and it was pretty solid. Not a very deep course but the concepts were very well explained.
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 better knowledge about managing it these days than when I was a kid. Just understanding the problem at a neurological level can help you build strategies to deal with it. You won’t ever find a magical cure, other than medication, but that’s another discussion. You probably will find ways to win, even if it’s a ugly fight.
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.
I started to but none of it described how my mind works and I lost interest. I got to the speed reading part before I stopped. I do speed read (because of dyslexia), but none of the preceding described me to any iota and I felt that it was most definitely target and written for neurotypical individuals.
Brain and autonomic nervous system activity measurement in software engineering: A systematic literature review
Abstract
In the past decade, brain and autonomic nervous system activity measurement received increasing attention in the study of software engineering (SE). This paper presents a systematic literature review (SLR) to survey the existing NeuroSE literature.
Highlights
• First comprehensive review on use of neurophysiological methods in software engineering.
• Investigation of 89 articles and detailed analysis of the 47 completed empirical studies.
• Identification of code comprehension as the most frequently studied NeuroSE topic.
• Increasing trend towards multi-modal measurements of neurophysiological data.
• Identification of the most productive authors in the field of NeuroSE.
Eternal dialog:
Ethos: Is it right to leave that pointer un-checked?
Pathos: It makes me angry that code reviewers let this through.
Logos: The code has bugs, don't act surprised, if you can, fix this one, otherwise put it in the team to-do list and move on.
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 read the first few pages. It was riddled with problems.
1. Section 1.1 shows an APL program "1 2 2 2 2 2 ⊤ n" and says, "The confusion here lies in the fact that you might not know what ⊤ means.". Nope. The confusion is that I don't know what any of the symbols do or how an APL program is structured. I expect this is the case for most readers.
2. There are 3 examples here. The discussions of the examples are not next to the examples. It is all jumbled up and hard to read.
3. The Java example spells main as mian.
4. Section 2 says, "programmers write a lot more code than they read". That is incorrect. For example, normally I read several of the solutions on Stackoverflow before I decide which one to copy and paste :-)
The "mian" thing is not an error. It's there to make a point about how the brain interprets code, depending on your familiarity with the language and problem. She explains it not much later on.
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, Manning, No Starch
Where's the No Starch judgment coming from? While they seem to have started veering into more mainstream/maker-y type stuff over the years, I've never had a single bad book off of them, and in terms of actual physical quality I'm not sure there's any publisher that's better.
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.
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 side effect of how difficult abstraction can be.
Heh, I get similar bitching from my team on this, but programming is basically the art of defining a structured language around a given domain. Naming is far less the bike shed and much more the assembly of bricks that build the nuke plant; the individual notes that make up the final composition, if you will.
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#
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.
2 replies →
> I highly recommend this series at least. > > [1] https://www.manager-tools.com/map-universe/politics#
From reading the topic overview, that looks great, genuinely good. However, there are about 30 x 25m podcasts, or about 12.5 hours of listening to do. In written form I expect that to be about 2 hours of reading (probably less).
Do you have any recommendations in written form?
1 reply →
Thanks for the link!
Most folk think that Computing is all technical but it is still a people business. It also helps me to think of it as people engineering.
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 interesting. It's part of what got me interested in the field. But it's not the job.
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.
well put
> 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 education + higher education. People who can't code at the end of the CS curriculum have three choices basically: HR, PMO or do a Master in a totally unrelated field to increase your employability. 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? I hope not. A "people person" is easily replaceable, a good engineer is not. When the financial crisis comes and the line is drawn, engineering skills remain. That is not to say that soft skills do not matter, quite the opposite, just don't make it a day job, you will become vulnerable.
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.
4 replies →
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.
2 replies →
Being familiar with this situation, I can tell you that this type of manager is only viable/typical in the outsourcing business.
> 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.
i'm not suggesting you should switch to a new role that is more of a people person role. I'm saying as an _engineer_, learning how to "politic" is way more important than learning a new language, or having a deep understanding of security, or some other significant technical thing. Not that those aren't good to know, but at some point the "politicing" will be your limiting factor if you can't play the game.
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 that way. Incredibly lucky to be able to pick and choose.
"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 understand those needs, how they interplay and interfere with your own, and how to participate in a way that gets people agreeing on how to move forward, while feeling their needs are met. It is, in fact, exactly what you say of "working well with others". The difference is can you work well with people whose perceptions and needs are completely different than yours (but who are still pushing for what they feel to be the best thing for the company)?
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. Some orgs may not know how to recognize it or to get rid of such people though (or have perverse incentives to encourage such behavior). But their incentive isn't that different; they're still looking to meet their own needs, but it's -their own- needs, rather than that of benefit to the business. I.e., "I want to be perceived as the source of success so that I get promoted, even if that robs my team of recognition" rather than "I want to make sure my team's success is recognized and compensated, so that our morale and performance can stay high, and so the org will trust us with greater responsibility".
5 replies →
Those who don't do politics get done by politics.
What you found are orgs with win-win (nonzero) cultures, where everyone's incentives were better aligned.
Identifying those safe harbors is a great skill.
Politics is inherent to any system comprised of human beings. There is no avoiding it and it always plays a big role.
We can abstract your statement slightly by saying that it is "scheming to meet a desired objective". Then, in a way you also played "politics" by crafting path in your career to the way you like; in a different way; likely without impacting life of others.
Overall, not all politics are bad.
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.
Not sure i agree with this one.
Plenty of places where purely technical people are appreciated, you just have to be willing to move around companies until you find a good fit.
That is not to say that you won't interact with other people within the org but politics will be less relevant.
In my 25 years of experience, I've observed that anywhere that a strong purely technical person thrives like that, there's an equally strong manager or leader behind the scenes supporting them, protecting them and clearing a path for them, even if they don't necessarily see it themselves.
That "good fit" you describe is (typically) the existence of that other person.
I don't say this to diminish the talent or accomplishments of that technical person in any way, but in most companies no one succeeds in a vacuum. It's almost always a team effort.
I think HN is a place that is quite focused on fast-growing tech companies and those are often (counter-intuitively perhaps) terrible places when it comes to workplace politics. This is because:
1. The fast growth creates demands for management and "senior dev" positions and since hiring is difficult these positions are often filled from within. This means that those positions will be filled with people who may not be ready for them yet, and who cannot properly control the politics that develop to compensate for that ("Oh person X is difficult? Just ask person Y instead, it'll be fine")
2. The fast advancements (with often come with large monetary rewards) also creates internal competition amongst employees on who will get to be promoted to the newly created position. This can seriously hamstring the company as teams of competing managers subtly sabotage each other.
3. Hiring from the outside is no panacea either, because this means that whoever felt they were "next in line" for a promotion is now faced with a newly minted superior who won't move away themselves in at least the next 18 months or so. This means that, if they want to progress in their career, they need to find another position either in another team within the company or at another company. The first option creates increased internal competition (see point 2), the second option creates increased turnover which costs money and causes loss of institutional knowledge.
4. Finally, just "being a tech company" can give the impression that workplace politics should be absent since "the tech is all that matters". This is untrue, devs are people too and ignoring interpersonal dynamics in favor of technology can be super problematic.
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.
It sounds like you’re at least partway into the journey of learning sales. Would love to know what resources you’ve consumed that were helpful to you
1 reply →
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….”
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.
There is a way out of politics. People hate being seen through. The more of a ‘ok, I see what you are about’ vibe you have going, the more self conscious they become. They often regulate down their politics. Just give people a solid death-stare, and I promise you they adjust.
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.
Ooooh, it's time to suck our own dicks!!!
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?
6 replies →
For me, speed reading is trusting that the comments are correct.
Speed reading is training your field of view. I would agree that speed reading code is not really useful (even though skimming code looking for interesting stuff is), but what is immensely useful is being able to notice changes on your screen in general. Did something go from green to orange in your IDE? Was there an interesting keyword in the logs flowing by? Did this icon just blink? Has this counter just gone up?
I'm often astonished by the stuff people don't see on their screens when helping them debug something. Replying to "how did you know?!" by pointing to the edge of the screen where some small blob went from green to orange or to red is something that happens more often that I'd expect.
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. :)
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.
That can't work well for anything non-trivial to read. Ever tried going through a math book like that? Did it work?
2 replies →
>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.
Felienne is also a host on Software Engineering Radio. If you are curious about the content I think a teaser of it is covered in this interview:
https://www.se-radio.net/2021/06/episode-462-felienne-on-the...
I appreciate that there are other people taking the time to create something like SE-radio, getting interesting individuals on to talk about interesting topics and then giving it away for free (I do not consider it payment to listen to an occasional ad for 10 seconds).
But I have tried so many times to start listening to SE-radio and always given up do to the audio quality. It is so grating when the interviewer and interviewee have drastically different volumes and quality.
This may have been fixed by now, as it has been around two years since I last tried.
https://corecursive.com/ is brilliant and typically has better audio quality.
Volume levels are relatively easy address so hopefully they have that under control. Quality is hard because you take your guests as they are and people often don't realize the how echoey their room is or how poor the microphone they have is.
I use Izotope de-reverb on my own podcast to improve the quality somewhat, but there is only so much you can do.
I believe she had an intermediate Excel course on either EDX or Coursera and it was pretty solid. Not a very deep course but the concepts were very well explained.
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 better knowledge about managing it these days than when I was a kid. Just understanding the problem at a neurological level can help you build strategies to deal with it. You won’t ever find a magical cure, other than medication, but that’s another discussion. You probably will find ways to win, even if it’s a ugly fight.
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.
1 reply →
Did you already read this one?
I started to but none of it described how my mind works and I lost interest. I got to the speed reading part before I stopped. I do speed read (because of dyslexia), but none of the preceding described me to any iota and I felt that it was most definitely target and written for neurotypical individuals.
Or, try this starting point:
Brain and autonomic nervous system activity measurement in software engineering: A systematic literature review
Abstract
In the past decade, brain and autonomic nervous system activity measurement received increasing attention in the study of software engineering (SE). This paper presents a systematic literature review (SLR) to survey the existing NeuroSE literature.
Highlights
• First comprehensive review on use of neurophysiological methods in software engineering.
• Investigation of 89 articles and detailed analysis of the 47 completed empirical studies.
• Identification of code comprehension as the most frequently studied NeuroSE topic.
• Increasing trend towards multi-modal measurements of neurophysiological data.
• Identification of the most productive authors in the field of NeuroSE.
https://doi.org/10.1016/j.jss.2021.110946
https://www.sciencedirect.com/science/article/pii/S016412122...
Awesome to see this published here. There was an episode on the SE Radio podcast about this book.
See: https://www.se-radio.net/2021/06/episode-462-felienne-on-the...
The author is also a regular host on this show. Highly recommend it.
Eternal dialog: Ethos: Is it right to leave that pointer un-checked? Pathos: It makes me angry that code reviewers let this through. Logos: The code has bugs, don't act surprised, if you can, fix this one, otherwise put it in the team to-do list and move on.
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 read the first few pages. It was riddled with problems.
1. Section 1.1 shows an APL program "1 2 2 2 2 2 ⊤ n" and says, "The confusion here lies in the fact that you might not know what ⊤ means.". Nope. The confusion is that I don't know what any of the symbols do or how an APL program is structured. I expect this is the case for most readers.
2. There are 3 examples here. The discussions of the examples are not next to the examples. It is all jumbled up and hard to read.
3. The Java example spells main as mian.
4. Section 2 says, "programmers write a lot more code than they read". That is incorrect. For example, normally I read several of the solutions on Stackoverflow before I decide which one to copy and paste :-)
The "mian" thing is not an error. It's there to make a point about how the brain interprets code, depending on your familiarity with the language and problem. She explains it not much later on.
I’ve always liked Manning…the one I can’t stand is Packt…
I have purchased exactly two Packt books.
One was actually fantastic quality -- one of the best ML/Python programming books I've come across.
The other was for some specialty GIS work, and it was tremendously terrible quality but the only source available.
6 replies →
Look at the table of contents for this book and make your judgement. I say no.
Yeah, Manning books have generally been in the "better than nothing" category for me. Don't know about this book though, it might be an exception.
That hasn't been my experience and I own quite a few of their books.
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, Manning, No Starch
STILL OK,GOOD = O'Reilly, CUP
Where's the No Starch judgment coming from? While they seem to have started veering into more mainstream/maker-y type stuff over the years, I've never had a single bad book off of them, and in terms of actual physical quality I'm not sure there's any publisher that's better.
1 reply →
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.
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 side effect of how difficult abstraction can be.
You looked the person up on github to mock their choice of variable naming. How...pathetic.
You talk as though it's a trivial problem.
I could probably fill 275 pages of my team bike shedding on variable names, so that seems reasonable.
Heh, I get similar bitching from my team on this, but programming is basically the art of defining a structured language around a given domain. Naming is far less the bike shed and much more the assembly of bricks that build the nuke plant; the individual notes that make up the final composition, if you will.
Not a guy.
Seems like only one of the chapters is on naming variables?