The Programmer's Brain
manning.com
manning.com
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".
There is some about IT in large enterprises/banks that for all intents and purposes, groom you to do exactly this
It is a spectrum, not black and white. The person you responded to just have lower tolerance for self serving bullshit.
People will fight their own company, throw other people under the bus, to ensure they're not being overworked and scapegoated, that they have enough budget to operate, some autonomy and say in the things they're working on. Conversely, when they don't feel threatened and aren't in the "survival mode", they'll start helping other teams and talk more about organizational goals, become proactive - whether because they care about the higher goals, or want to earn more status, autonomy or power.
There are, of course, sociopaths everywhere, but my gut tells me that for most people, it may be as simple as the model described above.
That is, if someone feels they'll be able to find a job outside of their current company, or that they have enough money to be out of work for a while, or that they're safe in the company even if they make waves, then they can optimize for their team's comfort above their own, and I'd contend that if you've ever had a manager you liked, they were doing that (even if it seemed like they weren't doing much).
So, sure, first it's Maslov's hierarchy of needs, but it's the one we're already familiar with; if someone feels their basic financial needs aren't contingent on people pleasing, then they can afford to not people please, and good employees, and good environments, encourage empowered individuals...but a bunch of empowered individuals may still have different priorities, which requires 'politics' to navigate.
If people -don't- feel their basic financial are guaranteed, then yeah, all bets are off.
Overall, not all politics are bad.
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.
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.
I highly recommend this series at least.
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.
And at mega corps with 400+ people, most projects are being bolted onto a multi million dollar money printer. There’s so much more process to getting big changes out. But if you’re on the right team, you can build something novel and immediately have a market to test it out.
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?
I just checked. This publisher charges for those. An interesting monetization strategy.
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.
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….”
Form relationships with people who are good at that sort of thing, who value you for things that you’re good at.
And it's not just about money, even OSS projects need a lot of push and support when the "fun" part is done.
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.
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.
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 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.
This is the same thing but from the other side.
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.
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.
Another aspect of writing code is to think about future speed readers. Can your code be skimmed and understood on a cursory level?
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?
While it is important to separate concerns where applicable (might be user related functionality and caching) generalization most of the time just adds complexity.
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!
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. :)
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'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.
https://www.se-radio.net/2021/06/episode-462-felienne-on-the...
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.
I use Izotope de-reverb on my own podcast to improve the quality somewhat, but there is only so much you can do.
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...
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.
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.
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.
There are very few cases where I would use Packt, and only after personal recommendations.
(edited to say Apress and not Packt. I'd forgotten which crappy publisher I was dealing with.)
https://github.com/rasbt/python-machine-learning-book-3rd-ed...
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
- How to make palindromes with python
- A CSS lexicon,900 terms defined (120 pages)
- The buttons of a PS5 controller
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 :-)
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.