300 karma · joined January 31, 2018
So, as happened last week, if I’m interviewing for an Elixir dev I’m going to be interested in your knowledge of the BEAM and how it’s features can be used to solve common architectural problems.
Current coverage is the US, more countries coming soon.
In essence I treated it like a junior dev who already knew the tech stack. So tell it what I wanted to achieve then pair program to get it working. Then iterate to add functionality. Once a feature is working, I could then ask it to help me understand how the tech stack was being used. Lots of fun, and very productive.
Webp encoded tiles extracted from the CoGs available on AWS then embedded within a pmtiles file.
I was seeing almost an order of magnitude reduction in file size compared to the CoGs with no visible image degradation.
They’re still not at feature parity with 2x the team, 2x the time and 3x the lines of code.
I thought that Elixir could do better and created a replacement Elixir monolith. The replacement happily handles the workload while running on my MacBook Pro.
I did resign, and started in a software architect role at a smaller company. Did that for a bit and then moved to become their lead data scientist.
I was in the eng. management role for nearly 10 years but kept my skills relevant by working on lots of side projects.
Trying to manage a team remotely through lockdown and the never ending dance of aerospace mergers and acquisitions followed by the inevitable reorganisation was largely what prompted the change.
Having watched it from the inside of one through 4 aquire/merge cycles over 10 years I speak from experience.
https://www.infoq.com/presentations/risk-project-management/
Know what you’re building but risk of schedule and budget overruns - waterfall and possibly earned value management (loved by the defence and aerospace sectors).
Not sure what you’re building so risk is you build the wrong thing - agile, get something minimal into the user/customer hands and course correct based on feedback.
No individual framework is perfect.
Set clear achievable short term goals with the individual that enable you to clearly identify and articulate their poor performance. Use that to reiterate performance expectations. If performance doesn’t improve, begin escalating with HR support (by that I mean tell them what you intend to do next and get them to sit in on formal meetings).
Having been through this myself it’s about ensuring it isn’t a surprise to the individual concerned that their performance is poor and creating the evidence that you followed a reasonable process leading up to any termination because worst case you and the Company end up being taken to employment tribunal. And that’s where your thorough notes and evidence that HR were advised on the steps you were planning to take are key.
And as a manager you have to pursue this because the wider team will know who’s not performing and be watching to see how the business addresses it. If you’re lucky the individual will decide to leave once they realise the direction of travel.
Good luck. And I recommend the book “Radical Candor”
Unfortunately our main contract was developing a component of a larger system being developed by our parent organisation who didn’t have a concept of systems engineering. We tried for years to educate them and I watched aghast as their program costs and schedule continued to spiral out of control.
Basically a bomb burst of engineers all doing what they thought was the right thing but no one owning the system design and saying no to good ideas.
In the words of their chief engineer “its like 10 different black boxes, I don’t know what I’m getting and I don’t know when it’ll be finished!”
https://www.amazon.com/Most-Secret-Penguin-World-Collection/...
To be fair, I think he was fighting not just Kotlin JS but using React within it and his own lack of web technology experience being predominantly an Android dev.
I’d just use Clojurescript.