Sorry, it's methanol that will make you blind or directly kill you. (Methanol is smaller than ethanol, so it's easier to build it in not-live chemical reactions.) Try again tomorrow.
I call these "romantic definitions" or "gesticulations". For private use (personal or even internal to teams) they can be great placeholders, assuming the goal is to refine vocabulary.
Fun times. Coolers, paste, fans, supply watts, dip switches and jumpers. Quake, Voodoo 3dfx vs NVidia GForce. This is where it all started, kids.
I was in high school and was running a "computer games club" (~ Internet cafe for games and kids) since 1998 when we got a place, renovated it ourselves, got custom built furniture (cheap narrow desks) and initially 6 computers - AMDs at 300Mhz. By 2000 we broke a wall in the adjacent space and had ~15, cable + satellite internet for downloads and whatever video cards we could buy or scrap. It was wild.
Finding high school kids with a similar "tech" background today seems really hard. Tech users, sure, chronic phone / game addicts are everywhere, but that tweaker spirit is rare
Good luck!
Fintechs targeting SMBs is a go-to-market strategy template that makes sense until you go to market and realize that if you have a better product, there's a better, bigger market and that market is the mid-market...
The thing with startups, like with SMBs is that most times are fragile, not-financially sound institutions. At least for startups, those that don't die, usually grow and need the larger scale features anyways.
Thanks! In general we optimize for simple UX and would rather connect to your banking app than replace it. That does help keep feature demand down. But our goal is to grow along with our customers, communicate closely with them, and add the features they need as they scale.
Consumers are usually a whole different beast. Everything is different with consumers from sales and marketing to regulation, particularly in the financial sector. I don't see how it could be a natural move, especially not with a treasury product.
There are exceptions, though, like Mercury, which expanded to consumers after having success with their business banking product.
Are you generating revenue or, otherwise, what productivity are you measuring?
Without generating revenue (which to be clear is a very good proxy to measure impact) everyone can be indeed very prolific in their hobbies. But labor market is about making money for a living and unless you can directly impact your day-to-day needs from your work, it can't be called productive.
Very valid point. I will lay down the facts for you:
At my previous employer, I was generating $2.5million per year (revenue per employee). I didn't ship a single line of code. All the time was spent trying to convince various stake holders.
Now, I have already built a couple of apps that help me better manage my tech news (keeps me sane) plus I am writing a blog that generates $0. It's only been a month.
If you measure the immediate dollar value, you are right. But in life, pay-offs are not always realized immediately. Just my opinion anyway.
I built a flash crawler to index all Flash while at Adobe. It started with Alexa top 1M I think then crawled. This was 2008-2010 I think so we had to do a lot of custom stuff, but we basically crawled then ran a headless Firefox with a custom headless Flash player that dumped a ton of data so also analyzed every flash at runtime and indexed all of that.
We built a dedicated cluster in a colocation center in Bucharest to handle all of this. Had issues with max floor weights and what not. Then had to upgrade the RAM on on the cluster. No remote hands. Every operation was a trip to a really cold place.
Used a lot of early stage stuff like Nutch, Hadoop, HBase etc. Everything was then processed and dumped to an SQL database with a nice UI on top. It took a few weeks to set it up, then we passed it to a team of interns that built the SQL database and UI on top. They learned a ton of stuff. Some are now in the Bay Area.
The tool uncovered a ton of security issues.
It was fun building it. I wonder if Adobe kept the data. It could be useful and/or good donation for the Computer History Museum.
Thanks for sharing. It's stories like these I've read since childhood that got me into this. Those little adventures into remote places to work on some computers. This was my version of Indiana jones.
It looks like there's a a bit of reversal in some areas (e.g. ML) and it may make sense to have more geographically distributed (edge) compute so maybe we'll get more diversity in the currently cloud-dominated space.
This said, it was always cool when we could control the entire stack, but the reality was that once we scaled things up, we had to throw things over the fence to IT, DevOps, SRE and whatever name evolutions there were and the reality is AWS/GCE/Azure made things easier than dealing with these teams internally.
>we had to throw things over the fence to IT, DevOps, SRE and whatever name evolutions there were and the reality is AWS/GCE/Azure made things easier than dealing with these teams internally
Anyone who was a dev during the "everyone is devops" fad for a while knows the pain of building something with these kinds of dependencies. Being able to claw back my time from operations on my company's dime is enticing.
This was around when we were trying to get Flash to work on the first iPhone, so we had a hackathon for a week. Since I was a distributed systems "hacker", I ended up doing what was needed :) and there were lots of questions related to the sizing of flash on web pages and what not. That's what started it - I simple python script that I refined during the hackathon to get the embed parameters etc.
But once I started processing the data, it became a thing and we made a small cross-team team to get this going. We eventually expanded the effort in a few different directions and wanted to do a Flash analytics, but ended up with the internal tool only due to privacy concerns.
I remember using that tool internally! Personally I think I only used it to get stats of which features/APIs were popular. But I think other teams used it for QA/conformance, like finding content that occurred in the wild but wasn't covered by test cases.
This has been a thought theme throughout my career and have a good set of scenarios I never ended up publishing.
It's not just the most "elaborate system". The same thing happens in so many other ways. For example a good/simple solution is one and done. Whereas a complex one will be an interminable cause of indirect issued down the road. With the second engineer being the one fixing them.
Then there's another pattern of the 10x (not the case with all 10x-ers) seeding or asked to "fix" other projects, then moving on to the next, leaving all the debt to the team.
It's really an amazing dynamic that can be studied from a game theoretical perspective. It's perhaps one of the adjacent behaviors that support the Gervais principle.
It's also likely going to be over soon, now that AI is normalizing a lot of this work.
reply