11–20 of 31 posts
So, despite what the author thinks about their methods and their technology choices and despite anecdotal intermediate performance indicators ("Solving bug takes ages") whatever they are doing is working.
How many start-ups do we read about on HN that are using the latest and greatest language/framework/stack/methodology and yet don't yet have a business?
> A big (2B+ $) company. The division in the middle of UK. They make Set Top Boxes - they are somehow good at that. So, despite what the author thinks about their methods and their technology choices and despite anecdotal intermediate performance indicators ("Solving bug takes ages") whatever they are doing is working. How many start-ups do we read about on HN that are using the latest and greatest language/framework…
I've been in a similar situation, though not nearly as dramatic. I've noticed the same effect: the talented people leave the company out of frustration. We talk about 3 people quitting in 6 months. In my opinion, it's a situation that happens when a B or C player manages to hire a B or even an A player. And here is how it happened: In my case, I was transfered to a company that worked in cooperation with my initial c…
I gradually fell back into development in my new job, did a computer science degree part time. Now I really enjoy programming/ creating.
There were warning signs before I ever accepted that job (which ignored because it was well paid). Now I know that money isn't everything and there's work out there where you simply couldn't pay me enough.
> A big (2B+ $) company. The division in the middle of UK. They make Set Top Boxes - they are somehow good at that. So, despite what the author thinks about their methods and their technology choices and despite anecdotal intermediate performance indicators ("Solving bug takes ages") whatever they are doing is working. How many start-ups do we read about on HN that are using the latest and greatest language/framework…
Interesting way to look at it. You could look at it another way and say what whatever they were doing before worked and got them this far. However, will what they are doing work for their continued future?
What would the technical and cultural cost of moving to a different toolchain be?
The author seems to think that obviously moving to modern tools would be better.
Would it? Or would it just add to the chaos? Would build times really improve, would debugging become easier and more streamlined, would issue tracking improve?
My guess is that changing the entire culture to the point where there were real, measurable benefits would take from a few months to a year, with a lot of unproductive downtime.
The current toolchain is not optimal, but it still sort of works. And in a limited environment like set-top, it will probably continue to work.
Bottom line: don't innovate tools for the sake of it. Innovate if it's going to give you more customers and more profit. But not otherwise.
There's this tendency I've started seeing more and more of in recent years. People pick an idea (be that a method, a technology or a philosophy) and make that their world. So you have people loudly proclaiming "We're agile", or "We're FOSS". This isn't necessarily bad. It does get bad when it's exclusive of anything else. When someone tells me they only ever do something one way, what they're really saying is "We're…
I've heard people describe themselves that way when they meant "We have no process", "We have a very specific process that we adhere to religiously, that has been billed as agile", and "We have a process that we are constantly trying to improve, through retrospectives and the like to figure out what works and what does not". Only with that latter one has the work seemed to get done on time.
All hardware companies I've seen on the inside are like this. Philips, FEI, Cisco, ASML, Océ. Somehow, when software isn't the only part that matters, people stick their heads in the sand and pretend like the 1980's never ended. I've given up trying to figure out why or change it. It's the only reason I only do web stuff now. I like both domains, but the hardware / embedded software industries are just retarded.
There is a reason they are "retarded" (BTW, please don't use that word). It comes down to the following:
1) Embedded engineers are generally EE that have taken a course or two in software. Generally they are the "best software guys" from a group of middling to poor software guys. As such, they reach for tools they are familiar with.
2) The product from embedded engineering is much different from web development. It might ship on a ROM, for a part with < 64kRAM. In circumstances such as this, knowing your toolchain won't add any complexities you don't understand is very important, and it doesn't get much simpler than C. (Also, most good embedded engineers use a restricted set of C that doesn't include things like printf and malloc.)
There's this tendency I've started seeing more and more of in recent years. People pick an idea (be that a method, a technology or a philosophy) and make that their world. So you have people loudly proclaiming "We're agile", or "We're FOSS". This isn't necessarily bad. It does get bad when it's exclusive of anything else. When someone tells me they only ever do something one way, what they're really saying is "We're…
Slight tangent, but, the funny thing about "We're agile" is that it means so many different things to different people. I've heard people describe themselves that way when they meant "We have no process", "We have a very specific process that we adhere to religiously, that has been billed as agile", and "We have a process that we are constantly trying to improve, through retrospectives and the like to figure out what…