The whole 'sociotechnical' part is gaping black hole for most new devs I meet, because it's not taught, and I don't know that schools know how to teach it.
Anyone have any internal processes (or resources) for helping newbs understand that side of the job?
starting from Organisational patterns, down. Skip anything there about design/ architecture/ math.
But: have in mind Conway's law - software-produced <=> organisation's-culture. So you can't dismiss entirely either of the two extremes of the socio-techical (human-machine) systems.
IMO, Winnie the Pooh has much more sociotechnical hints than CS university course.
* fear of writing original ideas, both natural language and code - agree
* the inability to measure things - who said this is something that is necessary at all stages? sometimes you just need it done. when you have 1000 people teams selling to enterprises, sure. If it is you and your buddies, no need to measure, necessarily.
* preference towards bias - Why? If it works, a good engineer won't go to the newest tech/framework. They will stay with their biased favorite.
* cognitive conservatism - Disagree. See previous comment
* inability to form assertion criteria - Not exactly sure what you mean, but if you mean to reason about code and state at various points, then I agree
People tend to preference their bias because they cannot execute more objectively and then frame that against a collection of logical fallacies and other nonsense as justifications and equivocations.
The inability to measure things results in a lot of really bad output often in preference for emotional comfort. This and cognitive conservatism are the most clearly identifiable criteria of poor cognitive performance by people who are in over their heads. I saw this at every employer when I wrote JavaScript for a living.
The inability to form assertion criteria means a person has absolutely no idea how to qualify a decision logically.
In most of these people tend to do Y at much greater cost because they cannot do X. The most common answer to this is anxiety and then people twist themselves into knots to somehow qualify that anxiety in a way that makes sense to themselves.
>who said this is something that is necessary at all stages?
understanding when you don't need to measure is important too. If you are just making a small 2d app as a hobby with no more than maybe 100 draw calls on hardware that exceeds that of a potato: I probably won't waste much time with optimization schemes and just crank something out.
But that same app may want to be kept as small as it feels so I would focus more on any assets being compressed.
> inability to form assertion criteria - Not exactly sure what you mean
I took it as testing. Unable to understand what you're trying to solve, frequency of usage for such functions/modules, the amount of reach your code will have (only used once in a small module? Code code that he core multiple layers up will rely on?) and not considering potential edge cases. More or less similar to what you said.
> Maintaining Culture: As the team grows, it's vital to preserve the company culture and ensure new hires align with core values.
I honestly disagree. You should allow the culture to evolve, but make sure it doesnt evolve in a direction that is different than where your values are now.
As an analogy, if you have a child who is 3, their culture is "energy", "constant learning", and "being cute". When they are 13, they should evolve beyond #3. And, they probably should add "be social/fit in", and "do good work (on homework etc)"
If you try to keep the 13 year old on the "being cute" value, you'll miss out on a lot
Meeting in person >1 hour away is difficult for people in many life circumstances. And if there are constant meetings, it either strains families or makes the person who can't make it feel left out
Totally disagree. For introverts, "everything public in slack" means that I would rather not say something than have 50 people see my thoughts/rants/silly questions in public
There's also such a thing as oversharing context with people that are already burdened with a lot of context related to their own tasks. Splitting off into private conversations helps keep irrelevant members from context switching.
From my experience working remotely for 2 years, this can be accomplished by starting a thread with a descript title and posting the body (with the context) inside the thread. Just like reading across a bunch of article headlines on HN.
For ongoing discussions about a topic, start a channel and perhaps prefix it "temp-" to indicate that it's a temporary channel.
1. As I said, the answer might help with the solution.
2. It's potentially misleading people on HN (which is full of employers and people's colleagues), about how other people with certain labels work and think.
The issue is what is best for the company. If a person is not asking or answering questions then they are not a valuable member of the team.
Keeping stuff secret and hidden does not help the project.
If your team is 50 you are probably not the only one asking the question and several people would be able to answer the question, limiting to one just annoys the one you asked if they are busy and someone else is not.
Hamas is a complex entity, the ruling party of Gaza as well as a militant terrorist arm. The population of Gaza is around two million people, all of Hamas is maybe 50,000 people, terrorist arm is some subset of that, and the people who actually participated in the Oct 7 atrocities are maybe a few thousand counting all support personnel. I think that easily qualifies as a few people compared to two million.
https://web.archive.org/web/20170809055122id_/https://learni...
tl;dr They did a qualitative survey of what other people think makes a great software engineer at Microsoft.
Their take aways:
- The ability to learn is more important than any individual technical skill
- Making good decisions is rarely discussed in the software engineering literature, but it is critical to being a great software engineer
- Software engineering is a sociotechnical undertaking
- Delivering the code is often insufficient; complex contextual technical considerations abound.