Thanks for pointing out Parcel RSC. I just read through the docs and they do a great job of explaining RSCs from a place I can understand. In contrast to NextJS where it’s unclear where the framework stops
I didn’t understand that myself until a decade ago. Before the gatekeeping starts (not by you), yes it got me through a 5 round behavioral loop at BigTech (AWS’s consulting department) and after leaving, now a “staff software architect” at a third party consulting company (both full time direct hires).
> ensure the project or major feature I was over was done on time, on budget and meets requirements.
The issue with this is that the bounds are drawn by someone else, the best you can do is 'meet them'. No one really cares if you save 90% of the budget, it was already allocated and will just get funnelled off somewhere else. It doesn't matter if it's early, because they probably didn't need it until they said they needed it, and 'meets requirements' is a given.
Compare this to a sales job or something more outward facing, a sales person might have targets but can blow them out of the water with some luck and skill (and get paid commission). They aren't operating within someone else's small framework, but a free variable against the open market.
It’s not that simple. It’s a negotiation up front if you are responsible for a feature/project. You talk to the stakeholders and let them prioritize what’s most important - budget, time, requirements - and you talk to them about the tradeoffs.
Your leverage comes from working on larger more impactful projects that have more impact and scope.
As a mid level employee I was responsible for smaller projects, now I’m responsible for larger projects with multiple “work streams”, more people under me and closer to the “business” and sales”
Also equally thankless when one team meets all goals/deadlines for their small product but the rest of the department is a dumpster fire — making the entire product suite unusable.
I like to call that not being on the critical path of company success: whenever you can, push to get your team onto that path, and if management can buy into OKR as methodology, which can help achieve valuable alignment (as long as they don't misapply OKRs for a regular "these are features we want").
This is why it's important not just to ask about previous results. This is also why you see so many "solve this random programming problem" type interviews - they hope (wrongly) that it's less fakeable and somehow gives you an idea of how they will do in the future.
I don't find those particularly useful (like many), i instead try to understand how they think and approach things.
If this is a manager, for example, give them real organizational problems you've seen, and ask them how they would approach them, and walk you through their thought process, etc. You will often start to get "weird" answers with fakers or spinners, especially if you start to ask about anything related to performance or improving it (again, in my experience, YMMV, etc). One idle theory (IE i don't claim this is correct in any meaningful way) i had about this was that a lot of the didn't actually know how to help people or organizations, so if you force them to try to explain how they approach it for real, they start to fall apart. Instead of thinking about that stuff, they were thinking about how to progress or spin things for themselves. Meanwhile, good managers often spend lots of time thinking about how to help their people and organizations, and whether they are good or bad or whatever, it's not a topic that tends to trip them up.
For IC's, for example, you can get them to teach you something real they learned on the project they claim was a great success, ideally a thing that helped make the project successful. In my experience, this also will lead you fairly quickly to discover if they believe they are smarter than everyone else. The best people i ever found (in retrospect) were usually the ones who would teach me things they learned, but usually not things they came up with. They would teach me something they learned from someone else during the project, but was still critical to the success of the project.
Everything in an interview is, of course, fakeable with enough preparation. The above things for sure - but it is harder for people to fake approaches, fake teaching, and spin results successfully all at the same time, etc.
You start to get into the "this person is in the 99% percentile of all fakers" kind of thing that is probably not worth trying to solve ;)
> This is also why you see so many "solve this random programming problem" type interviews - they hope (wrongly) that it's less fakeable and somehow gives you an idea of how they will do in the future.
Whether they can code or not isn’t indicative of whether they can get things done. The last time I had an open req last year, the coding part was ChatGPT simple. It was for a green field initiative. I needed to be able to throw any random thing that came up - a complex deliverable - and know they could run with it - talk to the stakeholders, disambiguate the problem space, notice XYProblems, come back with a design and a proposal and learn what they needed to learn with a little direction. I needed a real “senior developer”. Not someone that “codez real gud”.
I actually turned down a “smart” candidate who was laid off from the AWS EC2 service team I think dealing with Elastic Block Storage (EC2 encompasses more than just VMs).
I knew he could code. But he didn’t show me any indication that he could deal with the ambiguity on the level I needed or the soft skills.
I don't, except for trying to contact people at the job applicant's former workplace and ask "is this really what happened"? (I wouldn't do)
I'm thinking that as long as someone finishes projects you start, it's easy to take credit for all of it from start to finish, when interviewing elsewhere?
I’m not saying lie and I never have. But when you change jobs, you control the narrative.
At your current job, your history of both successes and failures are well known, even if the failures happened early on and you learned from them. You never get a second chance to make a first impression
Is that why Amazon's product search is terrible? Because it's more profitable for them when I scroll through 5 pages of junk than if I can navigate immediately to the thing I want?
It’s fascinating that Amazon Web Services have so many overlapping and competing services to achieve the same objective. Efficiency/small footprint was never their approach :D
For example, look how many different types of database they offer (many achieve the same objective but different instantiation)
As others said the product isnt the model, its the API based token usage. Happily selling whatever model you need, with easy integrations from the rest of your aws stack, is the entire point.
Trash on the flor has a known quick solution, a broken coffee machine doesn't and the fix often needs to be coordinated or you easily call in multiple people to repair it etc.
In general if a task needs to be coordinated you shouldn't try to do it yourself, at best you should notify a coordinator but usually they are already aware of it and you are just spamming them.
If you're interested in learning more the term to search is "takt-time planning", specifically as it relates to lean construction methodology rather than manufacturing.
I really enjoyed this, thanks for sharing. My takeaway is don't be afraid to put an unreasonable amount of time towards something.
It reminds me of PG's essay "The Bus Ticket Theory of Genius", which is like a hack on this idea. If you're obsessively interested in something, you're bound to spend an unreasonable amount of time on it.
Taking it even farther, there's a Revisionist History episode on the song Hallelujah, who's original version took over two years to write. The two components to "experimental" genius: time and iteration.
My team has been working on our app for 1.5 years now and of all the technical choices we've made, React Native is probably our favorite. It's taken us through the prototyping stage and all the way to production without many issues. Granted, we're a very small engineering team of 3.
Pros
- We haven't done performance tuning and haven't had any user complaints about performance (it's a multi-channel chat app)
- Most of the time, changes "just work" on both platforms
- Javascript :D
- Development velocity is great, especially w/ UI changes
Cons
- Wish we had better text input control
- You still need someone who knows about native app development on each platform
- Upgrading versions can cause breaking issues (this has gotten better)
- Lesser used 3rd-party packages are often incomplete across platform, so a fair amount of patches
- Changes on one platform have the potential to break the other platform (so testing can require a lot of back and forth)
We're building a chat app in RN. Last I checked, the RN components do not support the functionality that you mention out of the box.
We are using a fork of GiftedChat which has generally been a positive but not stellar experience (https://github.com/FaridSafi/react-native-gifted-chat). I understand includes some fairly clever (perhaps hacky?) and extensive changes on top of RN's components to mimic the interactions we generally expect in a chat UI. It's been performant for the most part but is quite opinionated.
I would love to know if there's a better, more modular solution out there.
We're also using a fork of gifted chat; pretty much use it for the layout measuring and the inverted scroll view. Hoping to move to FlatList at some point!
https://parceljs.org/recipes/rsc/
reply