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.
Personally, I’d aim for a new role at a medium or large sized company. Small startups are great if you want to wear a lot of hats and be close to the customer. Once a company starts getting around 50 people is when most of your job is abstracted through different fiefdoms of stakeholders, usually your project managers.
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).
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.
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.
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.
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.
There's a clear delimitation between the leader which takes decisions that impact the organisation and a project manager that barely has any skin in the game. In my experience, the one that takes decisions is not the one that manages people.
> 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".
I think it's a good default to think "this person is acting in good faith and believes their success is aligned with the company's success", but also recognize pretty quickly when people aren't arguing in good faith and not cling to the good-faith notion for so long that it prevents you from navigating the conflict situation effectively.
I wonder if there's a Maslov pyramid hidden in there. That is, people are first optimizing for their own comfort, then for the comfort of their team, and only then, for company goals.
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.
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?
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.
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 cause of redundant complexity.
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.
While it is important to separate concerns where applicable (might be user related functionality and caching) generalization most of the time just adds complexity.
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. :)
It does, but I will say that I had to learn how to block read math. So I couldn’t read until the 6th grade because of how bad my dyslexia is. I taught myself speed reading before I knew what it was (I called it block reading). I knew that my brain could recognize symbols and words without reading it so I took it to the extreme. I started glance reading; looking at the text and looking away and see what I comprehend. Eventually I was able to read whole sentences without reading each word or using a finger. I kept doing it so I could pass the reading comprehension tests in school. I got to the point where I could look at the page and flip it over and answer the questions. I wasn’t comprehending anything, I was just able to keep the entire image in my head and my brain gives me the answers. Kind of how it works for me know. I more absorb text than read 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.
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.
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.
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 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 unsurprisingly comprehensive and answers some questions that were of interest to me (like that a match expression turns into a jump table automatically if the data an be appropriately indexed, e.g., if you're matching on a u8) and covers macros which the book does not. The Apress book, on the other hand, is a hot mess and often actively wrong (and important things like the distinction between String, str, OsString and OsStr are simply ignored). If I wasn't just blindly requesting stuff via my library's online catalog, I would have skipped it because I've never seen a good Apress book.
(edited to say Apress and not Packt. I'd forgotten which crappy publisher I was dealing with.)
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.
