When the $100 system can run for 5 years of continuous production get back to me. I would be surprised if the system, as described, would work beyond a couple of days. Other than for emergency situations this isn't useful.
725 karma · joined July 14, 2010
The lesson for me was to never put in a day, week, … or year of work that I couldn't sustain because being able to get through the next day, week, …, year might be even more important than the current one. This was especially true as my startup started to grow. The first year had been stressful with just two of us working flat out, but once we got a payroll, yikes the pressure was multiplied. There are circumstances where a do-or-die effort is required but usually sustainability is much more important.
echo command | tee | ssh bash -seux
as this lets me ensure that command is exactly what I expect with full control over local vs remote expansion.
They are also already subject to "secret shopper" type monitoring under their earlier class action settlement for similar problems.
Uber just deflects responsibility, makes no improvements and continues to violate.
The result is UI regularly covered by the keyboard. Text clipping and text overflows. The tiny map problem mentioned in the article.
As much as I want a smaller phone I fear that it would be unusable with the default UI and certainly if I chose to use increased text size.
https://gist.github.com/bondolo/5ce1a1c0d38e72a80a79ac28f951...
I remember sending cheques to "Global Engineering Documents" in Englewood Colorado to get printed copies of various standards back in the 1990s and hoping that would die with the advent of the Internet and the possibility of cheaply distributing information. It was understandable in the world of paper that if you wanted some obscure technical document that it was expensive. They retained the publishing model but eliminated the reason it was expensive.
It has been encouraging that people like Carl Malamud have been working at making various aspects of our laws, regulations and standards public but more work is needed.
Some of my tweets over the years on the topic of open access standards:
"I am really thrilled by sudden attention on paywalled standards. Current model hurts standardization. So how about it @SAEIntl, @IEEESA, @NMEA_org, @isostandards, @ITUstandards will you join the 21st century and move to free open access standards? Alternative is your irrelevancy." https://twitter.com/mjduigou/status/1369033695030513670
"It annoys me that the IEEE standard for publishing test results probably won't be adopted by software industry because it is behind a fricking paywall https://ieeexplore.ieee.org/document/8662798" https://twitter.com/mjduigou/status/1273718847497887744
"I don't like that @IEEESA or @SAEIntl put their standards behind paywalls. Whatever revenue this publishing model makes is grossly offset by the impairment to, you know, standardization." https://twitter.com/mjduigou/status/1308889681187221505
"How many bullshit encodings have been created since 1984 because ASN.1 wasn't a freely available standard? Not that it is perfect but SO MUCH PAIN could have been avoided if there had been community adoption. That adoption didn't happen because it was not an open access standard." https://twitter.com/mjduigou/status/1308892326098546691
"Free the codes! https://www.kickstarter.com/projects/publicresource/public-s... Only slightly worse than patent trolls are public standards behind paywalls." https://twitter.com/mjduigou/status/384767046753320962
You can see the distinctive cool white LED "O" of Apple Park from 20 miles away in a plane. Why? Just vanity? The huge amount of light bleed serves no functional purpose. Lights, lights everywhere lights. Lighting up nothing. You can buy an intensely bright fixture at Home Depot and just mount it up making any location bright as day, but 24 hours a day. LEDs may have actually made things worse because of their low cost per lumen and long operating lives that encourages more and brighter lighting.
I am out of step in wanting a world with less human noise and light. If I complain about how noisy I find the bay area and how I would love to punch the Harley rider who lives a block away in the throat the most common answer I get is 'Wow, India and China are way louder' like that should make me feel better or unjustified in my complaint. In truth all it does is make me want to avoid visiting those places.
"Come by after work to meet the team and have a few beers".
I arrived around 7pm. There were quite a few people still around but to my surprise the tech lead who had hired me was packing up his desk into a box. I was kind of surprised but he seemed upbeat and glad to see me.
"Yeah, sorry to be leaving before you officially join the team. I got a great offer I can't pass up. Friends got their A round funding and it is an equity opportunity. You'll do great though. One piece of advice though,"
and he handed me three envelopes.
"Four pieces actually. Piece zero, and I'll tell it to you now. When you run in to trouble blame me. After you've seen my code you'll probably think it is shit. Hell, you're smart, you probably think everybody else's code is shit."
He continued "When you can't blame me anymore open the first envelope for the second piece of advice. You'll know when." and we went off to meet the team and have a beer.
I officially started on Monday and it was going great for the first couple of months. Then a product manager started breathing down my neck why one of my features was late. I had been frustrated with how hard it was to add the feature to the existing code and I found myself blurting, "The problem is not with my code, it is all of the old code I am having to rewrite because it is so terrible". I realized I was using the old tech lead's first piece of advice. So I continued, "Man, the previous tech lead's code is absolute garbage. It is amazing the whole thing hasn't fallen apart already." Since everyone looked sympathetic I knew I had made a good move. For quite a long time I made sure I was working hard or at least look like I was working hard and occasionally grumbling about the shit I had to deal with.
After a couple of months I was still producing at a good rate but I had now "rewritten" or at least claimed to have rewritten most of the bad code. I could not longer use that excuse. One Monday morning before the weekly sprint meeting I realized I was in a bind. I needed make sure that I had lots of work on my current assignment if I was going to avoid being assigned to a new project with "the customer from hell". I only had a few minutes before the meeting and after nervous peeing (twice) I still had no solution. I suddenly remember the envelopes. Digging through my messenger bag I found them and grabbed the first. While in the restroom for a third nervous pee I opened the envelope sitting in the stall. There was a card inside with one word "Refactor" and I had my solution.
A few minutes later at the sprint meeting I revealed that all my work rewriting the bad code, boy that was a lot of work, had revealed amazing opportunities to refactor the architecture and put us on a lot better footing. It would take a lot of work but I knew what needed to be done and it would really pay off. This proposal got a number of cautious nods and after a short discussion it was decided that I would proceed with a major refactoring of the product architecture.
A couple months later and my "refactor" was nearing completion. It did fix a few problems, the new APIs were more aligned with my personal preferences and I had gotten the chance to replace a few libraries with trendy ones that I wanted to get on my resume. Honestly though I felt like a fraud; my refactoring was just rearranging the deck chairs on the Titanic. I played out the ending stages of the refactoring but inevitably the time came when management was eager to use the new code in a product. Having no other option I agreed it was ready and that I was eager (not really) to see it shine in a product.
The first product to use it would be with another team. After the first meeting it was clear that they were really sharp and they immediately pointed out some shortcomings of my APIs and design. After a bit more wrangling they agreed that my module could meet their needs as long as I was dedicated to supporting it and them. My management agreed and they were now my customer.
Their product design proceeded and as they continued to get more experience with my module they kept finding new flaws in the API and bugs. I tried to fix them as quickly as possible but I was one person working to try to keep an entire team happy. I couldn't keep up. After a late night of bug fixing I was headed home exhausted in an Uber and wondering how I was going to be able to keep up. As I nearly drifted into sleep in the back seat I remembered the envelopes. I found the second envelope in my bag and opened it with the third solution, again one word. "Indirection".
Meeting with my "customer" on Monday I explained the bandwidth problems I was having meeting all of their team's requirements. I explained that what would work best is if they built a local interface in their project which called my API. That way the interaction between their system and mine would be localized and they would only have to make changes in one place if my API had to change. They had seen that I was tapped out trying to support them and agreed that they could build a local API which meshed better with their system that simply called my module to do the actual work. It took them a while to disentangle their code from my module and build their interface. By the time they came back with a few bug reports against the version of my module they had been using I promised them that I had much improved version to use. Once a few bugs were resolved the systems were again integrated.
They got closer to shipping their product and I kept getting bug reports from them that my library wasn't behaving correctly. I was forced to explain that the problems they described hadn't been there when they had integrated directly against my library--the problem must be in their local interface. Progress was being made towards shipping the product but there were still frequent mysterious problems.
Meanwhile my management was pretty happy with how integration of my code was proceeding. My director had talked about it as a collaboration success story at an executive meeting. My team members, who I had little interaction with as I was supporting the other team, were also congratulatory though they didn't seem to be as believing that I deserved my apparent success. I was pretty sure it was going to be a disaster actually. So when a college buddy emailed me about a business plan he was writing I offered to help. A few days later they were talking about me being the "Software VP" for their startup. I wasn't sure but it would be a founder position with equity so I couldn't just say no. I was trying to figure out what to do when I got an email saying that the team building a product with my module was having real problems with their scaling tests. They had done some analysis and were certain the problem was with my module, they didn't have proof, but had some pretty compelling analysis and wanted to meet tomorrow. Gulp. Just then my manager came by, apparently not having read the memo yet and introduced me to a fresh young programmer who was joining the team. He introduced me as one of the team's stars and he should seek me out for mentoring. I politely agreed but had other things on my mind.
Stewing in my cube without much clue how to fix the reported problems before the upcoming meeting I thought back to mentoring I had received and realized I had one more envelope.
Opening the third envelope I discovered the fourth piece of advice. It was brilliant. I called my friend and told him I was "down" to be the software VP for their startup, contacted the new kid on our team slack inviting them to come by for an overview on my module. I then sat down wrote my resignation email and completed the fourth piece of advice, "Recursion."
I left University of Alberta in 1989 after completing about two years of my degree to co-found a startup with the thought that if it failed I would go back to get a degree at a better program. The startup was a success and I have never gone back to school.
Sadly, in 1988 the University of Alberta CS program was stuck in a 1970s data processing curriculum and, for undergrads, had neither PCs or Unix. I had already been making money writing applications software for PC for several years and there was no way I was going to go work for an oil company or provincial government doing mainframes.
I did miss out on some things by not completing. I had very much wanted to take the compilers course offered by Jonathan Schaeffer (of Chinook checkers and poker bot fame). Had the U of A program included internships or co-op, more unix or PCs and a more modern curriculum I probably would have stayed. Indeed they closed the program to new students for a year in the fall of 1989 to retool it and modernize. The revised program was much better (In irony, I was hiring interns from the program about the same time as I would have originally graduated).
It is still strange when I have to explain sometimes that I have no degree. I can't imagine getting a CS degree just for the piece of paper. I can understand why someone might need that paper in addition to the skills, such as for a TN work visa. Thankfully I have not. If I did go back, and in my 50s I would feel like I was stealing a seat from someone who really needed it for their career, I would go for math, statistics instead of CS, a degree complementary to the CS skills already have.
New rule: if you don't condemn child rape every Monday morning then until you do it is assumed that you are in favour.
Tiny furors like the "who's wearing an American flag lapel pin" are is too often motivated by political opportunity rather than any real question of where the parties stand on topics. And yes, Democrats do it to Republicans as well, just generally not as frequently. Republicans seem to love their mostly meaningless and unsurprising performative doxologies.
Though I have done everything from kernel work to web development in my career I often end up working on or helping with the build and release engineering aspects. I will also frequently end up being the person who works on the product cybersecurity and security model.
It certainly isn't the most "fun" work but it is necessary and usually gives you a deep understanding of how the system works. This is especially true for older products.
Part of the problem you are facing is the assumption that by hiring smart people they are hiring people who can do anything, the people are interchangeable, fungible. Even if the "smart" part is true the willingness to work outside of their preference areas is not universal. Developers are often entitled, spoiled and fussy. And why not, with the variety of work opportunities and amount of choice available they can generally afford to be picky.
So it is not enough to say that you are a jack-of-all-trades, but that you are happier being that way and are explicitly willing to take on tasks/roles that may otherwise be hard to fill. This doesn't mean that they can assume that they will only give you the shit-jobs; it is still negotiated. If they want to you work on, for example, QA tooling and you REALLY hate that make sure to negotiate that the work is not open ended and for a specific project or time window. You are solving a problem for them, usually temporarily, and they still need to come up with a long term answer. Don't get yourself stuck in a rut of one particular assignment, it is too easy to wind up being stuck in that role for the rest of your time in the organization.
You can use staff turnover, particularly management turnover to your advantage. Every staff change creates a new configuration. Use these occasions to adjust your role and volunteer for opportunities which interest you.
A few months later, post the start of COVID, I heard that they were now really remote. I re-engaged and again inquired. It turned out that the job was only remote until COVID was over, again, after COVID they would want in-person presence in the office 3-5 days a week. This despite the team being globally distributed. Again I declined to pursue.
Then I started to see tweets advertising remote positions in the same group. I was asked on twitter by a former co-worker who works in the same overall organization if I was interested and I explained that I had already investigated and the lack of ability to work remote was a non-starter. He encouraged me to investigate again with his reference. The result was the same as before, London or Cupertino. Being truly remote or WFH in the bay area would only work until COVID was over. 1-2 weeks a quarter in the office was insufficient. I declined to pursue. Even the former co-worker was surprised that they weren't more flexible.
I am not sure what the problem is at Apple. They have had issues with remote work for a long time. I recall one incident where they fired a firmware engineer working on the CHRP Macs because he had to move to Montana (spousal or family reasons) and in the process really screwed themselves. A significant part of the CHRP project delays were because they blew a hole in their own firmware team. There had been a couple of people I knew working remote at the time Steve returned to Apple. All of them were let go if they didn't return to Cupertino. This had been a problem even before Steve's return though. Some of it is their silo "super sekrit" culture. It doesn't seem to have changed over the years.
In the end, Apple is entitled to have whatever culture they want. I have been a remote WFH since 1997. Unless I can walk to the office in 10-15 minutes I am never going to commute for anyone. That pretty much rules out ever working for Apple.
Combined with use of shellcheck and shfmt working in shell scripting has come a long way in the last couple years. I still feel like BASH is a dead end--the quoting and whitespace issues combined with the bifurcation caused by Apple not shipping Bash 4.0+ make moving to Python probably the better course in 2020.