I am so glad I rented a Tesla as a stunt for a friend’s wedding. After the sun set and the temperature dropped into the mid 40s (F) with high humidity, the touch screen practically stopped working. We were lucky we didn’t get stranded.
Zipping to 60 mph on the highway in 3 seconds was fun a couple times, but I would never own one. Especially if one guy could just delete my car if he decides he doesn’t like me.
To add another piece of personal advice - keep a log about pretty much everything you do, every day, like Picard with markdown. You will thank yourself later.
I have found myself in a similar position between independence and isolation in my role, though it's not as high-profile.
I am interested in the other answers here and will add my two cents.
Recent hiring: KEEP IT STUPID-SIMPLE. Being new at the company, less experienced, and empowered, you will probably be tempted by lots of "solutions," whether they're products, frameworks, management buzzwords, etc. Most of them are not designed for a one-man-team. Make sure your solutions actually help YOU.
Non-technical boss: AGREE ON METRICS. Your boss/es will measure you eventually, whether either of you are aware of it or not. It may be better to discuss some metrics while you have a chance to do something about it. At the end of the day, it's almost always about money (and sometimes ego), especially with cantankerous O&G types. Just figure out how you can show you enable, save, or make money within the system.
Feedback and standards: YOUR BEST FEEDBACK AND STANDARDS WILL COME FROM YOU. You are in a position to act on your best judgement, and then own your mistakes. Yes, you can feel like a fish-out-of-water a lot of the time. I have tried to find a balance between pushing myself to learn personal skills on projects, innovating for the company, just getting things "done," and keeping myself sane. Your peers, "clients", and supervisors are probably not used to (or aware of) "best practices", which is a double-edged sword. They might expect you to deliver things you know could be better, but you also have a ton of power to build a solid environment for yourself. Think of progress like driving a big boat, not a racecar.
I once replied "STOP" to a text-alert system I'd just been coerced into joining, and immediately received another text saying they'd stop.
The extra text really bugged me at the moment. Using iMessage through my desktop, I spammed "STOP" texts to the number as fast as possible, receiving the same auto-reply each time.
I wanted to see if it would hit some limit, and after about 200 texts, I stopped receiving a reply.
With JSON, sometimes you just need a fluent, permissive way to query objects that you don't already know a type structure for. This seems useful! I love JSONata for exploring json data, but it's more useful for static analysis than programming.
> Now, if you're paying attention and reading this with a critical eye something in your brain just told you "Wait, this is just waterfall! We can't know everything up front!"
The article presents the "story points" problem to be caused by an ignorant or presumptive misunderstanding of how the system works by outside parties.
I think articles like this are an interesting and necessary part of the overall project-managent discourse. However, they tend to infer that the problem of ignorance can be resolved by the management framework directly, to which I disagree.
Ignorance, regardless of project-management, has to be addressed by clear communication and boundaries.
A more constrained test might be justifiable on an interview, but it's got to be clear that it still doesn't directly translate to on-the-job skills.
This might be more of a question about what you expect from a "junior developer" role; are they building skills at a cost to the business, like a student or intern, or doing the best they can do to justify a paycheck?