There's so many idiots in the AI space that are completely ignorant of how Machine Learning works. The worst are the grifters that fearmonger about AI safety by regurgitating singularity memes.
We use Clojure at my work and it's basically functional Java with parens. No snottiness or evangelism needed. The fact that I don't have to write Java OOP boilerplate is a big enough advantage to me. Even if you just write it like Python or JS, it's still leagues better.
You just describe Boeing's relationship with HCL and Infosys. I had to get out because I just felt like I was wasting my life bullshitting and delivering zero value to anyone.
It's my first startup, but so good so far. I chose one that was older (8+ years) and had a fun stack (Clojure). Doesn't pay as well as FAANG but I get some cool lottery tickets (RSU) out of it.
I guess it's just a difference of nomenclature theb. FAANG (especially Amazon and Microsoft) are just so big that the stratification creates a lot of roles to facilitate the org. Even at my old company (~5500 staff), our managers only owned one product but I guess your RM would have an entire portfolio.
>A senior engineer is someone you can point in the general direction of a business problem. They rarely get requirements, and never fleshed out. Their job is to understand the problem in consultation with stakeholders, guide a team through execution, and maybe but not always write or debug some critical parts.
That sounds more like a manager or architect than an engineer. Engineers should take a proactive role in discovery and talking with business to figure out the best place to create value (that's a once a month meeting for us), but at the end of the day it's up to the PO to translate business needs into product development. Either way, I doubt you need 4+ hours a day to flesh out the technical requirements. When I worked at bigger companies, I'd spend only roughly 4 hours coding a day too. It's not because the problems were harder, but because there were blockers at every corner due to siloing and overly complicated business processes. I'd spend days in meetings and escalation emails just to get a networking rule exception.
>As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.
Then you're a sucker. Engineers are supposed to write code. Even at the bigger companies, all senior engineers (and I mean 15+ experience) wrote code most of the time and did everything in their power to avoid meetings and other disruptions. That's how I learned about the "Law of Two Feet". Business expects you to coordinate between stakeholders and the rest of the engineering team. What's next? Should you manage the team's budget as well? Make long-term product roadmaps? Get yourself a promotion!
>A senior engineer should spend the least amount of time coding compared to everything else they do during the day. If they don't, do you really need a senior engineer? How much of a 4 hour coding session is something you needed specific expertise in and how much is mindlessly typing the syntax with a big of logic peppered in?
What else are they supposed to be doing? If requirements are fleshed out then all you can do is get started. The bigger the change, the more you'll have to be concerned about architecture and implementation details. I think sitting down and thinking about the problem before you code is necessary for any dev, but I'm here to write the solution at the end of the day.
>If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special.
My company right now is about 15 people, 5 of which are engineering (including myself). When your team is that small, you don't have room for too many specialists. We're all capable individuals that can do the work without waiting for anyone. I'll get a ticket asking for a new web page, a new backend endpoint, DB updates, Et Cetera and it's the expectation that I do this all by myself. If there's something out of my wheelhouse, I can lean on my team but this is the exception and not the rule (and can still be done async). I don't know what special looks like for you but I can list the contributions I've made and the impact it has for our bottom line. In two months I reduced AWS spend by $5k/month, added payment enforcement logic netting us tens of thousands within the first week of its release, and seamlessly added a Huggingface NLP model into our AWS infra (our DevOps guy doesn't even know ML, he just treats the Sagemaker instance like any other resource). That's pretty impressive to me.
When I moved from a remote dev job at an insurance company (~5500 employees) to a startup (~20), I was amazed with how much more async the environment was. There are no core hours, everything is a thread unless an urgent need arises, and we're hardly on a zoom call outside standup.
What I've noticed is that I really do have more time to just do work. I end up releasing 3x a week instead of twice a month. I think it's still good to have refinement meetings and set time with the PO/Manager about vision and priority, but this idea that you need to spend even 10% of your time in synchronous discussions with your team is ridiculous.
Well, he decided that the whole world shouldn't hear about how the original founders of Tesla were removed and replaced with Musk. However, I can appreciate the distinction between muting people on your own threads vs removing people from the entire platform.
I'm confused, are you talking about banning Trump (after he lost the election)? I'm not saying the decision is right or wrong, but Twitter thought a long time about it. I'm pretty sure the board wanted him banned even earlier, but they waited for the right moment.
His whole life he's had to listen to shareholders. This is his one chance to just say "Fuck it" and just do whatever he wants. I would hope the businessman and him would prevent him from doing this. However like most gag orders he imposes, it would be completely hidden from us. He won't be tweeting about it.
Does anyone else feel like he's going to start doing petty shit like banning people he doesn't like (e.g. that musk flight tracker account)? He talks a lot about free speech but he has a track record of limiting speech on the platform (blocking multiple people) and off (making the founders of Tesla sign a hush contract).
>The one thing that really is rough for me with _both_ UE and Unity is that they're both very oriented towards teams with dedicated art people who can put out assets to use. BSP-based workflows where you can quickly greybox out levels to playtest (basically giving level designers without art sense a fighting chance) are much nicer with older engines.
That's because the value proposition with most games is in their art direction and gameplay - nobody cares how you get the polygon on the screen. I wrote my own game engine for a bit but then realized that all the work once the scaffolding was complete was in creating a fun game. Turns out that I don't really enjoy level editing and 3D modeling as much, so I stopped developing the project.
"Coding" in Unity and UE4 simply isn't fun. UE4's C++ macro abomination is bad but I find that 90% of the value in amateur game development is in the art content. Since I'm not an artist, I've simply given up game dev as a hobby.
Surprisingly enough, I'm a clojure developer and I really do like the hiccup syntax in Reagent. I haven't had the courage to use it in anything professional yet though.
EDIT: To answer your question, I actually think that JSX is a downside to React. I get that it was needed to convince the web crowd to adopt the library, but we need to stop pretending like we're writing HTML. We're not. The framework will take our JSX and do whatever it wants to it. I wish we just treated the DOM like a compilation target. That's actually what I like about Flutter - it treats the view as a render target and not as a document that you write to. Flutter web actually uses the canvas API to draw actually. And because of this, you can define your View model in a much more sane way (while still being fast). E.g. Flutter's Layouts make much more sense than HTML and flexbox/grid. They managed to separate the layout from elements. https://docs.flutter.dev/development/ui/layout
Yeah, but the function itself doesn't return that view. The framework you're working in essentially composes the view based on the associated code and template. This is fundamentally different from just returning the view itself in the function. These are all declarative approaches, but leaving your view in code is a lot better.
Every template-based framework I've seen has involved a lot of magic, syntax and DSL. That's not to say that JSX isn't a DSL as well but you can return regular React.Elements just as easily. You shouldn't need to remember a unique expression system just to be able to conditionally render. The premise that you're just not doing much with the data except dumping it into HTML is less true the more complex your site becomes. Think of the loads of conditions and evaluations that happen when you go to your Facebook wall or friends list.
If the only purpose of your site is to load some text or an image, go use a framework with SSG like NextJS. Then you get fast websites without having to pretend that writing stateful updates (e.g. jQuery) to the DOM is fun.