I try to think about developer experience in my day-to-day. K8s might make deployment for the DevOps team easier but more painful for the devs, and that's not good because they are the ones who make the company money. So work together with the developers if they're complaining to make it possible to ship code as fast as possible. If the devs don't like settings in yaml files, find a way to abstract that away (use standardized naming so there's fewer values they have to care about, give sane defaults that won't be overwritten 90% of the time).
The DevOps team's sole existence is there to enable developers to ship better code faster. If DevOps practices are preventing this, that needs to be addressed.
I don't agree with this generalization for good communication "In my experience more extroverted and “chaty” engineers have it better on average."
Often times we conflate loud communication with good communication. In my personal experience there are lots of verbose individuals that are poor communicators.
My personal experience with a room full of very smart introverts is that they do not communicate near enough information, or simplify it to the proper level. I assume it is because their expectation of "common knowledge" is much higher.
I was just discussing this with my girl last night. This is technically irrelevant to the overall context but in this specific comment thread, it's hard to figure out how to make content for the general population. I feel a lack of confidence because I surround myself with people who are smarter and better at things than me a lot of the time. So when I want to make them interested in something it's got to be super complex.
At the same time I see people watching a tutorial telling them how to put their OpenAI API key into a mass-adopted bot platform and getting "It's really cool you can do these kinds of things!" which is what started the conversation. Like it's cool they're trying, no shade to them but my baseline of what most people will think is interesting is so distorted.
> I feel a lack of confidence because I surround myself with people who are smarter and better at things than me a lot of the time.
It's not feasible in a number of organizations, but things like this are why it's important for developers to interact with the users of the software that they create. You learn so much more about what works and doesn't work for the users. You learn their vocabulary and assumptions about using apps which is often quite different from "power users" like we tend to be.
I look at it as signal to noise ratio. If someone communicates a lot but has a very low signal to noise ratio, parsing what might be valid from everything else, becomes a chore and adds cognitive overhead.
You don't have any idea what introversion means. Introversion doesn't mean withholding information nor being afraid to speak out loud nor being unable to synthetise information.
It does not mean to be shy, nor uncomfortable with people. Introversion does not mean exhibiting symptoms of autism either, which might be what you are talking about with "simplify at the proper level" (?).
Introversion and extroversion have absolutely nothing to do with the quality of a software engineer or its documentation. I just wish this label would just die, given how its misunderstood and misconstrued.
You had the opportunity to explain what introversion actually is, but instead this comment is only what it is not. I don't think that's useful if you are actually trying to help the commenter to which you replied.
Indeed. I'm an introvert who is in a leadership position at a large consulting company. My natural inclination is to be quiet unless things are going off the rails. But that doesn't work for the job I have, so I have to put myself out there more and communicate things much more explicitly and clearly than I'd prefer. But I can do it. I can lead calls and projects. I can "charm" CTO's with my ability to understand and breakdown the challenges they are facing. I can be persuasive and an effective mediator. But it's exhausting for me.
I spend most of my working day talking to people, and at the end of the work day I'm done with people and need to spend a significant time alone in my head to recharge. I doubt that any of the folks I work with would describe me as an introvert because the nature of my work doesn't allow me to fall into the comfortable isolation I'd prefer. At the same time, I can't have the impact that I do if I was the stereotypical "introvert" engineer which is what makes all the effort worthwhile. The biggest challenge with this is my intolerance for people extends to friends and family after work. A day full of meetings and I can't focus on conversations my wife tries to pull me into and I have zero desire to hang out with any friends. I literally need time alone to recover.
> It does not mean to be shy, nor uncomfortable with people.
introvert - noun - a shy, reticent person. [0]
At any rate, your comment is a pretty good example of what I'm talking about. Even if where I get my idea of it is off course from yours, you immediately become seemingly quite offended and start arguing your point in depth on trying to change what I understand as being a pretty global understanding of a word. You even kind of argue at the end that it is common usage.
I'm an introvert. I talk a lot, I like being around people but they tire me. The day I'm in the office, I feel like dying in the last hour. Thank god it's 90% WFH.
Either is fine IMO. I'd personally be more interested to have the person walk through their decision process than seeing the end result. Always fascinating to have someone explain it. If they copied and pasted it and hadn't been forthcoming it'll be obvious once the discussion gets to the meatier parts.
Do you thing the tech landscape today would have allowed for nebula to be born? Lots of companies now have strict IP agreements they have team members sign.
That's a great question! One of the things I enjoyed during my time at Slack was their willingness to contribute to open source projects. We had similar IP clauses, but asking permission to open source things was straightforward.
The most important concern (IMO), was considering whether we could commit to properly maintaining a project. Before open sourcing anything, you need to discuss how you'll go about managing an issue and pull request backlog, so that people don't come across "dead" projects under your stewardship.
In a high growth startup, I do think something like this could happen again, but as a company grows, there are certainly more layers that can make it difficult to share things openly.
Seeing as Slack was born as a tool inside Glitch which existed only because of a side project called Flickr…
I don’t really think it’s the size or layers of a company that prevent; it’s the culture. This culture of creation permeates everything I’ve seen Stewart Butterfield do. At least from the outside. Admirable and extremely profitable.
Why do we need a two month lead time now to ship a new static page?
How could we have drifted so far that we need kubernetes for that?
How is it possible that we need a platform team to build yet another later of abstraction from our cloud providers?
Why do we have more yaml than the code we're shipping?