31–40 of 115 posts
The guise of a Meritocracy is often just a flimsy pretext for competitive Nepotism. However, the ethics of posting a poorly written chat bots nonsense points to a deeper issue, We must consider if derivative copyrighted material when misappropriated by users is still plagiarism due to missing citations.
Earlier quoted context omitted.
What makes you say that about Python?
it's become a complicated language with many different ways to do the same thing but none of them very good
I had a similar experience when I got into software. As a junior, more than once I wished to just to quit the field - even after years of CS studies & it being one of the best opportunities one can have in my area. The draining nature of the "this is shit, we need to do clean code" and "TDD is the way" discussions being constantly repeated day-in day-out, can quickly kill any interest in working on code. It's not tha…
It's almost like children versus grown-ups. Children have simplistic, almost magical thinking. Adults know the world is more complicated, and the childrens' simplistic solutions don't actually work very well. One of the reasons is small sample size. Children don't have the sample size to see why their simplistic solutions don't work. Neither does a programmer with two years of experience.
My colleague has 22 years of engineering experience across a wide range of problem spaces and industries and team sizes (large bigco to mom/pop orgs).
Another guy (X) started was a year out of high school.
X insists that 'tech XYZ' is the best. Current tech stack was partially rebuilt by my colleague, but wasn't finished (because... lots of reasons, mostly resourcing).
XYZ is not only not a great fit, but the ecosystem supporting the problem space is small, especially considering what's already in place. Terabytes and years of data need to be migrated (both physically to new data centers and code-wise - new structure handling has to be added to accommodate current and future needs).
In planning meetings, "all voices need to be heard"... so X pushes XYZ a lot. And randomly rebuilds small bits in XYZ. And when it doesn't work - blames everything else (it's the network, it's the supporting libraries, it's ...).
The CTO will not push back. "That sounds great! That sounds like it'll solve all our issues!". There's a criminal deficiency in the understanding of the current tech stack or problems, along with no experience in migrating anything. But any criticism is taken as "we need to be more inclusive and let more people speak up - some of the best ideas can come from people who've not traditionally been heard".
Up to a point, that can make sense. But when do you draw the line? 3 months? 6 months? 18 months? People insisting on promoting child-like understandings of problems and solutions - while not ever delivering anything resembling a working solution - at some point should not be listened to.
Why does my colleague stay? He's only part time right now, and was close to leaving, but there's been some shift to refocus the CTO on something else, which may - over the next month or so - leave the few competent people there alone enough to get things back on track. I think if this was a 'full time' gig for him, he'd have left already.
Interestingly, I feel like this sort of attitude is a real issue at the precise moment the author describes it as a boon. When you are early to mid career, it is crucial to look for ways to amplify the good you can do in your workplace and solidify your brand as an individual. To do this, you should be looking, ironically, to elevate others. Doing so is the only way to build a reputation that people are going to acti…
The key is illustrated in the book club parable: The elitism is directed outside of the group and becomes only a means of alleviating the fear of judgement for misjudging the paper. The grad student's approach clearly communicates the socially agreed upon reality: the whole paper is crap. This stance and boundary provides a clear decision space to the learning junior members: "if you think you see a mistake, those here will be happy to hear it; no sacred cows".
Bringing this practice into a situation where the target is a member of the group's work changes the dynamics such that you have to mind your Ps and Qs again -- and so, dampens learning.
Earlier in my career I felt a lot of disgust at bad code and bad solutions. Sometimes it tye badness was really effort due to unfamiliarity or not instantly understanding what I was looking at.my laziness. Sometimes it was because it disagreed with what ever framework or methodology I was using to give me confidence in the face of ignorance. I feel like an imposter but at least I know design patterns so this guy who…
I think when I was younger I had in general more strong opinions on how to do things. They weren't really based on anything more than sounding like they were true. I'd hop on every paradigm that sounded correct. Clean code. Pure functions. Effective java. Pragmatic programming. Defensive programming. Like it has that righteous vibe to it. I'd totally strap a bucket on my head and go conquer the holy land under any of…
Whether you wrote 15 applications or just one or two, does that really matter? Designing, exploring, writing, iterating on and maintaining these applications _for years_ have given you insights, battle scars and tacit knowledge that can only be gained through experience and continuous learning. Not to mention the different environments technologies and foundational knowledge you explored and internalized.
You've accumulated a hard earned skill set and the ability make wide reaching, pragmatic decisions. Do you or someone else _know_ what the _best_ way of doing things is? Probably not. But I bet you have developed opinions, taste and a toolbox of approaches with different trade offs.
That's maybe where the OP is coming from as well. The mindset of being opinionated is very valuable if you can back it up.
That doesn't mean you're always right and don't let other speak. That doesn't mean you can't change your mind or that your approach excludes other people's perspectives and incentives.
It means you can strive for _better_ and that you're crazy enough to make bold decisions when necessary.
Earlier quoted context omitted.
it's become a complicated language with many different ways to do the same thing but none of them very good
I don't have many complaints about the language itself, but I've found the packaging ecosystem to be the most complicated and frankly dysfunctional that I've used in the last decade.
Package management isn't a solved problem; Python employs standard patterns for it; Significantly better than chained Makefiles from my C-development days.
I see a lot more elitism in relative beginners. Mid-career people tend to be more understanding and less judgmental.
Earlier in my career I felt a lot of disgust at bad code and bad solutions. Sometimes it tye badness was really effort due to unfamiliarity or not instantly understanding what I was looking at.my laziness. Sometimes it was because it disagreed with what ever framework or methodology I was using to give me confidence in the face of ignorance. I feel like an imposter but at least I know design patterns so this guy who…
I worked the majority of my career at an "elite" Japanese corporation. It's one that has a brand pretty much synonymous with "Quality." Many of my peers were among the finest engineers and scientists in the world. I was often the dumbest guy in the room, and I'm smarter than the average bear. Dealing with these folks could be infuriating . Every time I would suggest orthogonal approaches (because, like, software is d…
If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time - better to throw together something as quick as you can and rebuild it if it's actually going to be used by/sold to customers. That's really overengineering in my mind - doing a poor job with the quality/speed tradeoff given the purpose of the thing you're building.
Interestingly, I feel like this sort of attitude is a real issue at the precise moment the author describes it as a boon. When you are early to mid career, it is crucial to look for ways to amplify the good you can do in your workplace and solidify your brand as an individual. To do this, you should be looking, ironically, to elevate others. Doing so is the only way to build a reputation that people are going to acti…
This transition from junior to senior includes another important skillset: balancing social dynamics against engineering realities. The key is illustrated in the book club parable: The elitism is directed outside of the group and becomes only a means of alleviating the fear of judgement for misjudging the paper. The grad student's approach clearly communicates the socially agreed upon reality: the whole paper is crap…
In order to learn and make things better you _have to_ be critical. But the way things are communicated is very important so everyone is on board.
"We could do better here" - no matter who exactly was responsible in the past.
"This made sense at the time but with what we learned..." - remind each other that improvement and learning is part of the whole deal.
"I like the simple and expressive core idea of this, but if we expand this further..." - elevate and develop the good stuff that's already there.
I make jokes about my mistakes, bring them up early and often. Everything is a bit lighter and easier with a bit of humor and without the fear of making mistakes.
And vice versa it is just as detrimental to be afraid to bring mistakes and inadequacies up and criticize them. It's much more fun and productive if things are continuously improving.