I actually reverse engineered most of the code for the drivers for LeapMotion for my undergraduate project. Turns out it was illegal as per their TOS so my professor had me quit that project and take it offline.
The biggest problem I had encountered back then is that there was a packet transmitted with a certain signature in order to turn on the cameras that I could not reverse for the life of me (had something to do with the app version).
Other than that: basically two IR cameras that stream in an interleaved pixel format (2 x 640) x 480 iirc. It was a fun device to use and hack, but the first time I had ran into the brick-wall that is an enclosed format.
> LeapUVC gives you access to the Leap Motion Controller image data through the industry standard UVC (Universal Video Class) interface. This gives you low level controls such as LED brightness, gamma, exposure, gain, resolution, and more.
You can come up with a better reply of course. But can you really beat the "are we aligned in the same direction" from the CEO and the other executives? Especially on the 2nd day.
You can spin it however you want, come up with some great arguments, but if the CEO decided to fire people, I don't think he takes that decision lightly so when he/she presents that decision you can count that it really is the last option he has.
It all comes down to trust. Trust your CEO that he has no other choice, maybe explore alternatives. But if he is a really good CEO, even if you fight it and argue for it, you'll wind up at the same conclusion he did. In fact, 9/10 you'll wind up at the same conclusion he did. Remember, it's his job to convince and lead people so he's probably better than you at that.
CTO: "This is an important and disruptive decision. I feel that we need X more time to gather information and make sure we don't kill the company doing it incorrectly. What do you suggest?"
It's the CEO's job to be able to weigh different kinds of risks and make a decision. So bubbling up your concerns is the correct answer.
Spot on. This is surgery and requires precision, not axe work, and definitely not something that you're going to solve by coming up with some clever algorithm.
Intra-team relationships are super important, as are the degrees to which the team members have arrived at the company, how long they have known each other, whether they knew each other prior to their arrival and so on. Before you know it you have a mass walk-out on your hands with those that have options leaving first.
The best way to deal with this is to do it very gradually and taking great care to not inadvertently wreck the core structure of the tech department.
Basically any reply that buys you more time so that you can make an informed decision: this demonstrates you can act in the best interest of the company instead of blindly following CEO's orders in order to keep your post, with potentially disastrous consequences.
In the beginning, you are on an island, you have an idea to go on an adventure, so you start building a raft with the other guy on the island. The other guy has no building skills, but he procures food, water and wood. The resources on that island are dwindling but you manage to finish the raft just in time.
You begin to sail the raft, you start fishing while out in the open seas. You reach another island and sell the fish, figure out that is the way you can have an easy life since you can pay other people to procure food, water and wood with fish. You build a better boat, hire more people and repeat the process.
You now have a huge rowing boat that goes very far out at sea since there are no fish left close to land, you now fully depend on the people on that boat to make it alive to the next island. There are people who row, people who fish, people to cook, people that are on the lookout for fishing spots and islands.
Your partner notices a guy who eats more than the average rower on the boat, but rows less. You throw him overboard. A fire starts near the rowers, but the rowers continue rowing. Turns out the guy you just threw overboard he always put out fires. You find another rower, tell him to put out the fire. He throws water over it. It is now worse. You figure out the fire is the cook's fault for using too much oil. He only used so much oil because the lookouts thought fish oil is good for their eyes so they can see more ahead. You know this to be only partially true, but they don't seem to understand and even though the fire happened they still demand their food fried in fish oil.
You throw one of the lookouts in the water to make an example. The lookouts stop eating deep fried food. Now the people who fish complain they work too much. Turns out the deep fried food gave the lookouts energy to shout at the people who fish where to fish at. Now, the people who fish need to stop what they're doing and go to the lookouts for information. Because of all the extra effort the people are doing, you are now out of fresh water in the boat.
Congratulations, you now know how a CTO feels like.
This makes me wonder, considering the cost of acquisition of talented staff why I don't hear about more large companies with lots of capital on hand requiring that people instead of being fired, just asking them to take a period of paid leave.
It would have to be for a while to shake out issues, but if you suddenly discover you need the person, then they're not gone. You also get to experiment with different team combinations to see if the problem was a management issue, or if they would be better suited in a different role?
Obviously you still need to fire people now and again, but this large scale firing followed by huge hiring cycles always seemed a bit odd.
The bar to be fired in large bureaucratic companies is usually pretty high. Like you'd have to physically assault your coworkers or steal money from the company account.
It makes zero sense to keep people who are being fired, they are being fired for a reason.
If you're talking about normal employees. They can take holidays anytime (what's the holiday allowance in the US?). Large companies usually have a concept of sabbatical, you can take a large break (let's say 3 months) after some years of service.
> It makes zero sense to keep people who are being fired, they are being fired for a reason.
The problem addressed here was "is my reason valid".
If you fire someone for the wrong reason, and then everything crumbles, having them on paid leave for 1 month or 2 won't hurt the company financially, and allow to test "how are we doing when X is not there anymore".
And that's exactly why middle managers in large companies have zero power to fire. They can't be trusted to fire for valid reasons so they don't get the ability to fire.
Gotta go through HR and due process, that typically sets the bar to assaulting coworker and stealing from the company.
1) It'd all be better or at least the same without any external interference from you
2) The positive outcomes to the business are more a result of external factors like market expansion, word of mouth, a new fad, rather than your own contribution
The impact you can make as a CTO is bringing an engineering perspective to the board and keeping engineers happy (either by doing it personally or by delegating to someone else, eg. a VP).
Both are important tasks because it's easy for business to start thinking of engineering as just a cost centre (which is the easiest way to make sure your company will never use technology efficiently to multiply its revenue) and because hiring engineers costs can be a significant part of your company spend
As an engineer speaking to someone who is clearly also an engineer - you're highly discounting the levered impact proper, high quality leadership makes on a business.
I put myself in those shoes and wondered what doubts I'd have about the contributions I could do. The OP was a great illustration of the chaos it can be. I wasn't saying that leadership has no impact, that's crazy.
Sounds like a bad captain, entirely reactive and not proactive at all. Those people were brought onto the boat to perform these duties but were given no oversight? Why didn't the captain have any knowledge of the fires that were happening so often? The captain had no idea what was being used by the cooks? He didn't talk to the people who bought the fish oil? Never had a meal with any of the lookouts or fishermen?
The captain should be the one to jump overboard in your story.
CTO of a small-ish startup here. Here is my take on it:
1) Code doesn't really matter as long as it solves the issue you are trying to solve. Don't expect your code to be beautiful from day 1. Be responsible and train your devs to be responsible as well, because in a startup you code, fix and deploy your own stuff.
What does matter, though, is code complexity. Manage your complexity, don't overcomplicate things if you don't need to. No need to design a Ferrari when all you need is a horse and carriage.
2) Process matters. From day 1, make code reviews/pull requests the default. If you are the most senior dev, or a technical founder/CTO in a small startup be prepared to spend about 50% of your time reviewing code and helping others. You won't get to code as much, but you'll sleep better at night knowing at least you've tried to catch some bugs before they reach production. In an early stage startup, you will not have the time nor the resources to test everything, but this will give you peace of mind.
3) Tests matter. That being said, in the beginning only test mission critical stuff. If you find a critical bug, fix it and then write a test for it. If a new feature breaks something that already works it is a big no-no and might lose you customers. Testing will change for you as you progress with your startup. Start by making the process easy for the devs to run the tests locally. Then, progress in having CI. Then, maybe have CD as well.
4) Worst case scenario: full rewrite. If a 6 to 12 months old startup decides on a full rewrite. I'll give them the benefit of the doubt, maybe their whole use-case has changed, maybe they DO need a rewrite. That's fine. But, if you are a SaaS that is older than that and your dev team is around 10 devs and they are all busy solving critical bugs and putting out fires, a rewrite might mean your death.
5) Architecture matters. This matters more than code, in my opinion. Say you have a horrible piece of mission critical code, it is SLOW and begins affecting your business. That piece of code will need a rewrite, for sure. But what would you rather do: spend 30 days to fix it and lose customers, or just spin up another machine/add CPU/add RAM? This is a good architecture, it allows you to have time to think things through, allows your code to run well and perhaps most importantly, allows your developers to actually code.
Bad architecture is the leading cause for rewrites. Is that beautiful microservice architecture giving your small team headaches? Did you overcomplicate things, perhaps? You see, bad architecture is very hard to fix. People seem to underestimate how much a simple API + DB can scale and try to mitigate the risks by copying whatever FAANG does. Start small, scale later once you have the resources to do so.
TL/DR: Code quality doesn't matter if you solve your issue. What matters more is mitigating the risks that come with writing code in general. See above for some ideas that came from my own personal experience.
As the CTO of a small-ish startup, this rings so true. All our employees were hired from our network. Its only now that we'll look for other sources to benefit or hiring pipeline.
Octave is amazingly written, in my opinion. I remember delving into its source expecting a mess made by mathematicians and instead found a very well organised and clean code base. Kudos to that team!
Totally agree with what you said, but there is a caveat no one tells you about when you start Elixir. Coming from CUDA the extra speed you might get with concurrency in Elixir seemed very enticing for me so naturally I began experimenting. In Erlang/Elixir processes are really lightweight, but they do still bring some overhead and, in most cases I experimented with brought no speed advantage whatsoever and were in fact slower.
For example, lets say you want to compute the first million fibonacci numbers using the series' nth number formula.
The function below calculates the nth fib number in the sequence; Then, to keeps things simple, we look around in the Elixir documentation and find Task which accepts a closure, is async and spawns a new process. Great you think, with the extra speed from parallelising in blocks of lets say 1k fib numbers we'll surely be faster.
def nthFib(n) do
round(:math.pow(@phi, n) / @sqrt5)
end
1..1000000
|> Task.async_stream(MyModule.nthFib)
|> Enum.map(fn({:ok, result}) -> result end)
Nope. In fact, doing it naively with [0, 1, ... fib[i-1]+fib[i-2] ...] is faster. This was a bummer for me.
If you're interested and want to test something on hackerrank yourself, take a look here for a post I made while first experimenting with Elxir's processes on overoptimizing the first Euler problem. Noob thread here: https://elixirforum.com/t/hackerrank-optimizing-euler-proble...
Of course it might be just me, trying to apply the same principles I learned using CUDA. In my defence, those principles served me well over the years no matter if I was using CUDA or solving concurrency problems somewhere else. If anyone is interested in pitching in, I'm open to ideas, but for now I'm going to continue thinking that Elixir is fast enough for most use cases, just don't get your hopes up thinking its a silver bullet.
The biggest problem I had encountered back then is that there was a packet transmitted with a certain signature in order to turn on the cameras that I could not reverse for the life of me (had something to do with the app version).
Other than that: basically two IR cameras that stream in an interleaved pixel format (2 x 640) x 480 iirc. It was a fun device to use and hack, but the first time I had ran into the brick-wall that is an enclosed format.