Live data from Hacker News

The Most Dangerous Email (to my career) I've Sent

notyourlanguage.com

71–80 of 85 posts

Re: The Most Dangerous Email (to my career) I've Sent

#71
post #67

Earlier quoted context omitted.

And one should have that right, but whether one should exercise that right is another matter. A thought experiment: If you could pick any point in history and make it so all people expressing socially unpopular views were permanently cast out from society, and all other people never spoke or traded or dealt with them ever again, when would you choose to freeze social opinion? Which modern day group of normal every da…

Really upping the ante if my personal morals lead to banishment of another. This was in the context of choosing business partners when I had the option. Not all of my beliefs are likely to be perfectly rational such that I could objectively defend them. That still means I can pick and choose my friends without casting the rest to oblivion. If the question is, “What happens if all of society rejects X group for their…

Sure, but my larger point is that I believe people should strive for free speech maximalism even in their private dealings, and even within the private dealings, we should strive to make the consequences we impose minimally "dangerous". There's no bright lines to be had, and everyone will have different limits, and every situation will have different criteria applied to them. But overall I'd rather err (and see other people err) on the side of being too permissive rather than not permissive enough. On the scale of less to more permissive, I'd probably argue that the order would be something like "friends", "business partners", "employees", "contractors". The less likely you are to be inviting someone over for dinner, the more permissive you should probably be over how their outside speech impacts your business dealings with them.

People only change by exposure to new ideas, and if all the "bad people" and all the "good people" never mix, then what hope do the "good people" have that any "bad people" will learn to think differently?

Basically, I really don't want to live in a world where it's normal for my boss to go trolling through my HN comment history before deciding whether I get a promotion or not, no matter how much of a right they have to do that. I'm not ashamed of the things I've said here (to the best of my knowledge), I just don't think that having a discussion with other people, about topics that don't directly bear on my work should be used when determining how to treat me at work. I am not so conceited as to think I am right all the time or that my bosses would agree with every thought I have. Which is why I have these discussions here, with other people engaged in the topic and not at work, with my bosses who weren't talking about the topic in the first place.

Re: The Most Dangerous Email (to my career) I've Sent

#72
post #2

The title might be a little dramatic, but I poured my heart into this article. I had to make some drastic decisions and big changes with regards to my career trajectory - and if I can inspire others to be true to themselves, then I'll be happy.

The dangerous thing to me was not the email, it was asserting the misunderstanding that additional years results in inutility.

"Up or out" doesn't have to mean up the org chart. It can mean up your value through mastery, which you clearly feel you have within a set of disciplines.

It took some number of years to become "the best" at those things you described being good at. Whatever activities you were doing those years that made you the best, keep doing them … applied to adjacencies.

Later in life, after people have been good at some things for a while, it's an ego boost. They forget what it felt like to be not good at things, and that that was OK. They become inhibited from learning by both ego pain of doing something badly, and mental pain of reformatting brain and behaviors to fit in new learning.

If at 40 you have 20 years of getting good at things, at 60 you can have another 20 years of getting good at additional things. Innovation and mastery of systems comes from multi-disciplinary, multi-system understanding. The additional years can make you more useful, not less.

Arguably, it boils down to: do you like learning, and do you like what you do. If yes to both, there's no reason you can't keep accumulating ability to deliver value.

Re: The Most Dangerous Email (to my career) I've Sent

#73
post #17

> I felt like by 40 I needed to move on from engineering because if I didn’t, I’d be like the few older workers I’d dealt with in my career. I felt like they moved too slow, were stuck in their ways, and unable to change - even when faced with evidence to the contrary. If that was your fear, then I'm sorry you had that fear, and I hope it was unfounded. Unfortunately, there's externalities to voicing a negative stere…

>> I felt like by forty I needed to move on from engineering [or] be like older workers [who] moved too slow, stuck in their ways, unable to change

This is a terrible idea. It's not age, it's attitude and approach.

I replied to OP on this here: https://news.ycombinator.com/item?id=41405231

Not mentioned in that, adding here: You can't invent viable things unless you know the stuff of which they are made. Bigger/harder/newer things are built on more/harder/newer stuff.

Deep learning is largely incompressible. Practical (applied) mastery takes 10,000 hours times the things you need to know.

Ergo, always keep learning, use "more years" to outcompete by sheer accumulation of understanding what new things are made of and how they work together.

Become that staff eng, principal eng, or engineering fellow who can, and does, do more impactful things.

But only if it's a fit: https://growthco-op.com/wp-content/uploads/ikigai-1-1024x968...

Re: The Most Dangerous Email (to my career) I've Sent

#74
post #28

Earlier quoted context omitted.

I'm also very wary of being stuck in my ways, but even after all that bias-compensation, I still hold the belief that the fastest/most maintainable/easiest/best for the user way to make web apps is server-side rendered with minimal JS (mostly to enhance components). I don't know if this makes me a dinosaur, but I firmly believe that the best way to make 95% of modern websites is Django+HTMX (or similar), instead of a…

My belief too, as a grey beard 25 years in. I’ve seen all sorts of shit come and go. There’s a lot of “slack” in the industry that we get away with. Ridiculous incidental complexity, far-out frameworks, architectural astronautics etc. But if you care about “adding value” or your business succeeding, tools like Rails/Django are way to go. (And btw, use a RDBMS ffs)

Oh yeah, the RDBMS is the other big pet peeve of mine, but luckily the tide seems to have turned towards those pretty thoroughly.

Re: The Most Dangerous Email (to my career) I've Sent

#75
post #61
post #28

Earlier quoted context omitted.

I'm also very wary of being stuck in my ways, but even after all that bias-compensation, I still hold the belief that the fastest/most maintainable/easiest/best for the user way to make web apps is server-side rendered with minimal JS (mostly to enhance components). I don't know if this makes me a dinosaur, but I firmly believe that the best way to make 95% of modern websites is Django+HTMX (or similar), instead of a…

This is the way a lot of people feel lately, and it's nothing to do with being a dinosaur. It's a whole movement. I'm wary though, because lots of things start nicely but fail to manage complexity of even a moderately sized app, and everything grows over time. I feel like a lot of people are going to rediscover why we started making everything a SPA. There have been a lot of approaches on the frontend over the years…

> lots of things start nicely but fail to manage complexity of even a moderately sized app, and everything grows over time

Is it size, do you think? To me it's more about how much interactivity you want the app to have. If I'm making an online shop, I don't think I'll need tons of interactivity, so I don't see the codebase ever outgrowing simple SSR views. If I'm making something much more dynamic, then I probably would go with an SPA from the beginning.

What kinds of things have you seen that made sense to start with Django but then had to be split up, and why did they need to?

Re: The Most Dangerous Email (to my career) I've Sent

#76

Earlier quoted context omitted.

Since you mentioned Gaza and Palestine, I assume you are against Israel’s response. I don’t want to turn this comment section into that at all. I just wanted to say I feel that I can’t speak in support of Israel. The opposite can also be true. Again, not wanting to turn this into a Palestine/Gaza/Israel thing just pointing out that people on the other side feel the same way.

In the US the more mainstream position is to support Israel, and only recently has there been a semblance in the change in trajectory. That's why both major parties come out in support of Israel.

That was The Onion’s position as well:

https://theonion.com/the-onion-stands-with-israel-because-it...

Re: The Most Dangerous Email (to my career) I've Sent

#77
post #75
post #61

Earlier quoted context omitted.

This is the way a lot of people feel lately, and it's nothing to do with being a dinosaur. It's a whole movement. I'm wary though, because lots of things start nicely but fail to manage complexity of even a moderately sized app, and everything grows over time. I feel like a lot of people are going to rediscover why we started making everything a SPA. There have been a lot of approaches on the frontend over the years…

> lots of things start nicely but fail to manage complexity of even a moderately sized app, and everything grows over time Is it size, do you think? To me it's more about how much interactivity you want the app to have. If I'm making an online shop, I don't think I'll need tons of interactivity, so I don't see the codebase ever outgrowing simple SSR views. If I'm making something much more dynamic, then I probably wo…

Yeah a lot of complexity is driven by interactivity. If a component needs to become interactive that presents some new problems, especially if then other components need to update based on that as well. Lots of GUI apps get bogged down by complexity, the web frontend is not special in that regard. There are lots of patterns in desktop development as well--just look at how many different frameworks Microsoft has run through. Interactivity can get messy quickly and that was something reactive programming helps with a lot.

But if a project starts out with minimal JS and it grows complex, then it has a hard problem. If it was previously templates, there are going to be a lot of APIs that need to be made to convert from form posts and ajax. Some sort of framework is important to help provide guide rails for the team to avoid the mess, and they expect to update the page and don't play well with whatever was progressively enhancing the site before.

The other problem is that if it was just templates and a minimum of JS, then there probably isn't a frontend team in place. Most of them want to work in $fancyFramework and not on HTML templates. They don't get paid well for HTML and won't come to work for a company slinging template code. The backend devs don't want to do HTML, either. So it becomes a people problem. At some point in the complexity growth, a hard gulp is made to higher some frontend folks who are immediately unhappy. I've seen this play out several times and it results in big rewrites and stalled company growth.

So yeah, a lot of times we just start with React. Because there's not a great path from minimal JS into additional complexity. And you can hire people for it who'll be productive immediately. And at least there's no gotcha down the line when complexity grows. To do otherwise seems to always end up with rewrites that are so long that the team who finishes it isn't the same team that started it.

In Django, I love a good monolith. I try not to split them up and even ran a top 100 site for years using a Django project, as have others. It's generally a good time to break up a Django project into smaller Django projects when the team size is big enough to support dedicated people for features. Around then it starts to get frustrating to manage deploys and CI and testing and all of the peripheral stuff. But disciplined coding in a monolith can take a team a long way.

Re: The Most Dangerous Email (to my career) I've Sent

#78
post #74

Earlier quoted context omitted.

My belief too, as a grey beard 25 years in. I’ve seen all sorts of shit come and go. There’s a lot of “slack” in the industry that we get away with. Ridiculous incidental complexity, far-out frameworks, architectural astronautics etc. But if you care about “adding value” or your business succeeding, tools like Rails/Django are way to go. (And btw, use a RDBMS ffs)

Oh yeah, the RDBMS is the other big pet peeve of mine, but luckily the tide seems to have turned towards those pretty thoroughly.

Yeah the NoSQL tide seems to have been stemmed by people actually trying to use them.

Re: The Most Dangerous Email (to my career) I've Sent

#79
post #77
post #75

Earlier quoted context omitted.

> lots of things start nicely but fail to manage complexity of even a moderately sized app, and everything grows over time Is it size, do you think? To me it's more about how much interactivity you want the app to have. If I'm making an online shop, I don't think I'll need tons of interactivity, so I don't see the codebase ever outgrowing simple SSR views. If I'm making something much more dynamic, then I probably wo…

Yeah a lot of complexity is driven by interactivity. If a component needs to become interactive that presents some new problems, especially if then other components need to update based on that as well. Lots of GUI apps get bogged down by complexity, the web frontend is not special in that regard. There are lots of patterns in desktop development as well--just look at how many different frameworks Microsoft has run t…

Nice, thank you for the reply. You're definitely right about the people problem, it's too bad that nobody wants to do the simple thing. Thanks for the insight about when to split up a Django monolith, we're definitely not there yet, and we're going the other way (consolidating).
Post reply on HN