Yes. I just had a bad experience with an online shop. I got the thing I ordered, but the interaction was bad so I sent a note to their support email saying "I like your company, but I recently had this experience that felt icky, here's what happened" and their "AI Agent Bot" replied with a whole lot of platitudes and "Since you’ve indicated no action is needed and your order has been placed, we will be closing this ticket."
I'm all for LLM's helping people write better emails, but using them to auto-close support tickets is rude.
For me it was management. I was an SDE who started caring more about the users of my code than about the code itself and that led me to a team lead position and that led to management at a small company and that led to management at a big company. I found I really like mentoring junior engineers and I'm a good sounding board for senior engineers. I got to spend a lot of time saying variations on "Hey, let's not do that thing that won't work, let's do something easier that will work." I also focused a lot more on my career and making money rather than most of my life which I spent focused on cool tech and that got me to a place where I could retire easily when the time was right. Now I code for fun and I still chat with former colleagues from time to time and get to say things like "Yeah, but you know option B is the right choice so go do that." None of it was clearly planned, all of it was stressful but in the end it sort of worked out.
Can you share more about your experience regarding how management at a small company lead to management at a big company? Was the switch voluntary, and how did you do it?
The short version is I got lucky. The slightly longer version is that at the small company I was doing tech lead things because I learned I could get more done to help people by helping organize the other engineers. Then when my boss quit to go sail around the world I was offered his job. I was now a "manager" but initially I still acted like a tech lead, writing a little code, taking care of the database, that sort of thing. The nice thing about the small company was they gave me space to learn and lots of mentorship. I got to see all the numbers on the business side and changed from being the "Let's write something new in Rust!" kind of developer to being the "But what's the simplest thing we can do to help our customers now" kind of manager.
Then I got a call from a friend I had worked with many years agi who was staffing up a new org. He needed people and had a very big budget. This is where the "career" part came in. I had a job with people I really liked, making okay money and could probably work there until normal retirement age. The new job offer was much more risky for much more money and I was always bad about taking risks. So I took a lot of long walks with my wife and we talked about the upsides and the downsides (upside: _so_ much money. Downside: What if I'm no good at the job?) and in the end I took the job. The job was in another state and my son only had two more years at one of the best high schools around so I got a small apartment and flew home every three weeks.
It was an incredibly learning experience. My new manager jokingly explained to me that my new job was people and if I was looking at code I wasn't doing my job. I took that to heart. I met some amazing people. I went to an insane number of meetings. I also got paged awake at 2:00am to be low-key yelled at by a group of Irish people because a computer in India wasn't getting enough network traffic and had run out of entropy. I think I helped some junior engineers with stories like "Ha! You think that was a screw up, let me tell you about my friend who turned off amazon.com for 6 minutes many years ago." And I learned the trick of going toe to toe with a senior architect in a design review meeting by asking "Okay, but what if these two things I'm picking at random happen at the same time?"
In the end it worked out for me. I saw other people go from SDE to SDM and then go back to SDE after a year because it wasn't a good fit for them. They were better engineers for having spent a year in management, but they didn't like it at all. Also I'm typing all this with the benefit of hindsight and probably making it sound easier than it was. I made lots of mistakes in my career, but going into management turned out okay for me.
And now I'm trying to write a Smalltalk VM in Rust and no one in Ireland is waking me up at 2:00am. I got lucky.
why a vm for smalltalk vs. one for some other existing language, or designing and then implementing one of your own?
just interested, because i am also working (very early stage) on a language interpreter. only in the idea and thinking of features stage so far. also, i am new to this area. but i find it fun.
It's worth keeping in mind that lean manufacturing and all the interesting things that Toyota did that get written up are about building cars. In software the equivalent process is compiling and deploying code. Writing software is equivalent to designing, prototyping and testing a car. So while there are many interesting lessons to learn they are about the deployment and running of code, not about writing it. In the mass manufactured automobile industry you spend more time and effort building the product than designing it. In software you spend much more time designing (specs, coding, testing, all that stuff) the product than deploying it. The lessons of lean manufacturing may not apply to design.
Lean manufacturing and the Toyota Production System are absolutely about manufacturing. It's rooted in industrial engineering and operations research. It is about addressing root causes and truly solving issues. What we see in the lean books is a bunch of solutions to problems Toyota was facing at the time and how they solved them.
Even the person who coined "lean manufacturing" says, "Don't try to bring lean manufacturing upstream to product development. The application of Lean in product development and manufacturing are different. Some aspects may look similar, but they are not! Be weary of an expert with experience in lean manufacturing that claims to know product development."[1]
There are a couple of books that have tried to capture the design process from Toyota. [1] is the Wikipedia page for [2]. [3] is an alternative take. Unfortunately I haven't read these books, so can't provide anything beyond the table of contents.
In my experience, whenever a site installs lean processes, somebody gets the bright idea that if it works in manufacturing, then surely it can work in R&D. Every senior (hardware) engineer has a story of this happening at a past workplace.
The compromise is to tidy the workplace as well as possible, call it "5S", fill the dumpster with stuff that's really junk, and let each engineer stash their Undecidable Things under their desk.
As for software, maybe the best thing is to just not let hardware concepts such as "designing" and "manufacturing" creep in. Especially when those things imply a social hierarchy.
Yes! I still meet too many people who think what we are manufacturing software, while what we are doing is designing it. The manufacturing, that is, the building and deployment is already highly automated and very cheap.
A significant percentage of the time you’re researching software — determining if something is even possible.
This is the even more crucial difference and the reason for all the time estimation arguments.
If a manager can’t estimate a car production run schedule they’re a bad manager.
No manager can schedule — to the day — when fusion powered cars will be ready for shipping.
Yet, this is expected from people trying something entirely new in software.
“Integrate these two things that no human has put together before. Now that you’ve heard this single sentence, tell me: will it be ready Tuesday or Wednesday… a year from now?”
This is why Agile/Standups make people go crazy! The daily standup makes sense when all the topics discussed will close out within hours, blockers sometimes stand literally upstream on the assembly line, and no one can really talk to each other outside of the standup because they’re too busy running manufacturing work centers that need 100% of their constant attention.
Imagine if compiling/deploying involved teams on the daily hand writing assembly/machine code from code base?
The lessons of lean manufacturing may not apply to design processes themselves, but a lean transformation in manufacturing often relies a lot on certain design choices (poka-yoke in assembling, standardization to cut setup times, etc). Design is often one of the most important factors in successful lean companies. I totally get the point, though.
His shelf seems to be an almost perfect superset of mine, the only obvious thing I don't see is Fire In The Valley by Michael Swaine and Paul Freiberger, a very nice history of the early PC revolution in Silicon Valley. I should probably get him a copy so I can just use a picture of his wall with the stuff I don't have blacked out.
Networking. Every time I see a non-technical friend have to know anything about the DNS to set up a website it makes me cringe. And while we're at it, why isn't my new laptop online by default? I realize that there are tremendous problems of configuration and security, but I should be able to unbox my laptop and not care about how many G's there are what the wifi passkey is or what the letters CDMA stand for. It should be as invisible to the end user as memory management.
There's a product called the Efergy True Power meter that does exactly that. It measures mains electricity, wirelessly reports to a central server and shows you real time and historical graphs of energy usage at sub-minute resolution. http://efergy.com/us/elite-true-power-meter
When this happens in dictionaries it's called a "ghost word" and dates back to the 1800's. Here's the wikipedia page on the topic http://en.wikipedia.org/wiki/Ghost_word
I think the author is making an excellent point about needing better math in journalism. An article in the NY Times yesterday about online shopping China had this line (pulled from a press release) "Tmall.com, one of Alibaba’s shopping sites, said Chinese bought...two million pairs of underpants, which if linked together would stretch 1,800 miles..." Why should I believe the rest of the article when the author is quoting someone saying that underpants are 57 inches wide?
To cross check your claim about the author, I did:
1800 miles ~ 2000 miles
5280 ft/mile ~ 5000 ft/mile
So 10M ft / 2M underpants = 5 ft/underpant. 12*5 = 60 in/underpant, which is close to 57, so I trust your statement :)
Sorry, but you Americans need to get rid of that imperial system: 1800 miles ~ 2000 km = 2,000,000 m. Each pair is around a metre. Simple, isn't it? Okay, admittedly, 1800 miles is definitely more than 2000 km...
I'm a little confused by the conclusion that "It is up to donors to do their research and donate in a way that will maximize the support they provide for charities." I gave a 10 year old Honda Civic with 198,000 miles on it to KQED. A truck showed up and took it away and I got a tax deduction. The car ran okay but didn't pass the California smog test and the chances of me selling it to a third party were small. I got what I wanted, an old car taken away for very little effort. I chose KQED because I'm a big fan of public radio. It was up to KQED to maximise the amount of money they got for it.
Point is that taxpayers are subsidizing your gain in disposing a car that isn't worth the book value, as well as the process of transporting and selling the car, and KQED might not get much money at all.
The problem isn’t that the car isn’t worth the book value. As the article stated, you can only deduct the price that the car gets at auction. The problem is that you deduct the gross auction price rather than the net amount that the charity can use. It comes back to the question of how much overhead a charity should have (see also Dan Pallotta’s talks that have been making the rounds).
What I don’t understand is what prevents a for-profit service that provides hauling, and returns to you the auction proceeds minus hauling fees and zero value insurance. Then car owners would have a real choice between pocketing ~50% of the car value and giving it to charity and getting only ~30% as a tax deduction, and they would be less likely to give the car to an unsavory profiteer.
Assuming your car has to be towed away (for whatever reason), financially, your best bet is to probably sell it to a junk yard. They will tow it for you, and throw you a couple hundred bucks.
My impression was that towing is more about convenience for the donor rather than operability of the car. This way, people donating cars don't have to coordinate dropping off the vehicle at a location and then getting home.
I think there are plenty of really really good programmers who are lousy negotiators. For these people a 15% cut could easily be made up for by a good agent. It's not perfect for everyone, but for people who are better coders than business people it could easily be a win.
reply