Want to second the two parent comments to this. Small freelance / contract team of very very senior very experienced people. 3 to 4 max.
I was fortunate in that I, for the first part of my career, joined teams that were structured like this.
Some additional thoughts:
- keep things small at the start - task your team with at least two goals for the first 90 to 180 days
i ) to define a small but critical piece of work (actually designing and coding something related to what you need to do). Cannot be part of your core platform but will need to eventually be in the platform. Picking the right piece of work here is critical.
ii ) to define a design, roadmap and project plan for completing everything you want done with cost, staffing, tech and effort estimates
Then use the 90 to 120 days and the two tasks above to evaluate:
i) if the folks and team you have put together works:
a) as a team and
b) with your existing business ( can they do the work, can they work effectively with the rest of your business, is the design the come up with solid and does it give you confidence that they can tackle the real core work you need done)
ii) if you can get a sense of what it will cost (what did the 90 day project cost and was it delivered on time and budget per the team's estimate )
iii) if the team can put together a road map with support of the business for the broader objective in parallel to executing the piece of work chosen
iv ) if the solution if palatable from a cost perspective ( money, people, tech, disruption )
v) if the staffing model , architecture and integration proposed for the project by your new team could work (get feedback from the rest of the business about what is proposed by your new team )
vi) if your business can work with this new tech team ( feedback from your existing staff about the folks doing the work and their product for the small piece of work they tackled )
- It is really critical that they be 'senior' people - 'senior' here meaning they have done and seen a lot. The title will not tell you if they are. You have to actually look at what they have done. Look for senior free-lancers with a variety of (longish 4 to 5 years) experience using a variety of technologies (C / Java / PL-SQL / Perl / Rust / C++ whatever etc etc - but boring old tech is better, you will eliminate another variable from your project complexity ) in variety of industries / verticals ( 3 to 5 industries. This is a signal of effectiveness at learning new things and delivering effectively in new fields with new people in new environments.
- it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you.
- Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ).
- Key skills to look for in free lancers:
- systems integration (making systems 'talk' to each other - you will have to make your existing system talk to your new system + you will eventually have to get your data off wherever it is now to your new environment and you will have to make the new system work with all the other tech systems you have now)
- system architecture: designing software solutions
- database architecture & design
- project & program management
- lean six sigma / green belt ( means they have may have worked with ops people to optimize operations )
All the difficult stuff is going to happen in the background (batch processing, integration etc etc) so don't bother with front end development skills at the start - that is actually relatively easy to hire for.
You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc).
- Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing.
- Plan ahead for what WILL go wrong.
I strongly strongly strongly recommend reading two books
- The Phoenix Project - https://www.amazon.ca/dp/0988262592
- The Unicorn Project - https://www.amazon.ca/dp/1942788762
They deals with how executives and staff tackled a situation very similar to what you are dealing with and explains how to tackle some of the key structural problems you WILL run into. It is also a great resource for understanding how to run a project like this and understand how things could go right and more important, how things can go wrong and what to do WHEN they do go wrong (because they WILL ). The books will give you a very strong set of foundational thoughts about how to think about running this project if you decide to commit to doing it.
I've been going through a similar situation in a smaller company, and this is one of the best comments I've ever seen on HN.
Any given operation may not be able to follow all of it to the letter, but all of it is really sound advice and can be tweaked/customized for a variety of settings.
I do not think that there is any confusion or misreading of the numbers here.
Without dealing with the specific points made in the piece, I would argue that there is gap in understanding the premise of the piece.
The article starts with numbers but it is not a analysis of quantitative measures i.e. is it not a statistical analysis.
The article is an "outside-looking-in" qualitative argument with an attempt to support those quantitative arguments with quantitative values (this is called competitive intelligence in some circles).
In other words, it should be read as an "opinion piece" with some numbers in it: the numbers are not the point, the (subjective ) opinions are the point.
I get it that numbers can be used to make a point either way (i.e. the author could use "confusion about numbers" as way to make a point while there really isn't any confusion ) but the points I would take away from the argument about numbers are:
- the fundamental premise behind putting the numbers in the piece is to make the point that they are not the same numbers that:
i) the org has put out in the past
and
ii) other similar businesses have used and continue to use
- the number are definitely designed to be impenetrable no matter how you approach them
To quote the author:
"When a company starts playing weird games with how it reports user activity, something is going very, very wrong. In general, when a company starts trying to obfuscate the true numbers about its revenue, growth, or profit, it’s a bad sign."
But why should we give any credence to these opinions? Certainly not because the author is an expert on the subject, their background appears to in PR. Nor because the author is showing any kind of understanding of the subject; actually the opposite, given the multiple basic mistakes made in the opening to this piece. Like, it's not even that he got the facts and reasoning wrong. It's that he has so little understanding of the space he didn't realize that there had to be an error somewhere.
And it's not like the rest of the piece isn't full of links to purported facts. The author clearly can't be trusted on presenting the facts correctly nor interpreting their interpretations correctly, so you'd kind of need to fact check all of it. That's a lot of effort just to properly evaluate this tripe.
The only reason to pay attention to this is that they're writing something you want to believe, in a style you find appealing, and don't really care whether any of it is true or not.
> - the fundamental premise behind putting the numbers in the piece is to make the point that they are not the same numbers that:
But that fundamental premise is wrong. Meta has released comparable numbers in the past, which is exactly GP's point. And releasing aggregate user numbers across multiple products rather than per product is a totally standard practice.
A clarification comment here to help explain what is going on here- re: the 'non-native' part of the comment above.
Swahili specifically is a second language to a population speaking a very very diverse set of first / primary languages.
Swahili is spoken in East Africa - Burundi, Congo, Kenya, Uganda, Somalia ( southern tip) Rwanda, Tanzania.
Kenya and Tanzania have the largest part of speakers and in Tanzania, there are over 20 'first' languages and in Kenya , there are at least 20 'first' languages as well.
Also important to note that Swahili is formally taught in primary / grade school, alongside either English or sometimes French, to a population that already speaks a different first language used by a much smaller population.
The point here is that there are many many first languages that are sources for "borrowing" into Swahili but that borrowing has to be adopted across all Swahili users who will not share that first language.
This means that only the 'easiest' / 'lowest friction changes' make it through over time into Swahili as all words also have to be accepted by speakers having other "first' aside from the ones that each word or language component was 'borrowed' from.
38-in-1 is some random storage media (USB stick, DVD. SD card, CD ) with "38" (or 45 or 2, or 99, pick a number) media files (movie, TV show, YouTube series whatever ) in various resolutions, formats, modes etc sold for next to nothing in the street.
Can be played Android-type boxes or even on phones / tablets
Essentially sneaker-net but for watchable media.
Not something you will see in much of in NA or Europe but very common in Asia and Africa where bandwidth /internet and more important, electricity, is relatively expensive.
The 90 minutes with your family comment is spot on.
in NA and Europe, this is mostly because folks don't have access to continuous internet. You are in back-country or don't have service or whatever.
In the Africa / Asia case, its because you don't have internet and / or power.
Most of the time, this media is viewed off TVs running on batteries, charged by solar, off an USB port. The electricity budget (because battery) says you get "90" mins of TV a day (not exactly 90: the power is shared between lights, charging phones, would be be more time but because electricity is limited, "TV time" is limited).
So those "90" minutes are family time, we all watch the same thing together.
Point being, in that world, Cam or SD of whatever works, no need for HD, or UHD or 4k or 8k - it is completely worthless. The screens that the content is being watched on are 720p most of the time.
Something like this (edit replaced original link with a new one that explains what is happening better)
I think this is also the reason most "scene" releases of TV shows and movies were xvid encoded, and capped at 175MB and 700MB respectively for so long. So that they wouldn't break compatibility with burned CDs on existing players.
They have an office full of people processing cheques, cash etc etc. In the old world, all cheques were processed by hand but in the new world, all cheques are processed by a combination of electronic imaging and MICR: people only look at the ones where tech processes fails. Which are a lot of them.
This area of finance is called "Corporate Cash Management" - a bit of misnomer because it is not just cash and is primarily electronic these days. It is essentially about the processes that need to be in place to physically and electronically move money around.
Here are some examples of what the biggest bank in Canada offers in this space.
The do not explicitly mention cheques because that space is really well automated these days but it is mostly done really well by technology and most banks are trying to move away to electronic payments. But if you ask for it, you will get it at specially quoted per customer rates.
Peak "$XXXXXXXX" database is when your particular flavor of DB is completely consumed into traditional RDBMSes.
Vector databases (and all other incremental or transformational improvements) are just features of regular plain traditional RDBMSes that have not been implemented in traditional RDBMSes yet.
I have seen every new DB tech subsumed by traditional databases over time as compute capability improved.
No exceptions.
The list is endless:
- object databases (e.g. blobs, JSON)
- OLAP
- in DB programming ( XX-SQL eg PL/SQL, T-SQL, ANSI-SQL)
- column-oriented data stores
- key-value
- graph databases
- No SQL
- Cloud, distributed, whatever
- statistical analysis databases
- document databases
All these used to be standalone, very expensive, specialty products but are now just one more checkbox on the Oracles/SQL-Servers/DB2s of this world.
All these have been swallowed by the borg of commercial databases without so much as a burp.
There is no winning the commercial market long term for these products. Big business buys traditional RDBMSes because they are the kitchen sink. They do EVERYTHING and they will eventually do this new hot thing, the business will just have to pay big dollars for it. Which is not a problem for big business.
There is a reason that cartoon about the Oracle org hierarchy was made (bottom right): all the company does is make product (Engineering) and protect that product. And it is very good at making good product.
Traditional DBs already kinda support vector DBs via pg_vector extensions and such.
There is a YC startup, latnern, that also built their own extension for postgres that is open source and is better for vector DB use cases: https://github.com/lanterndata/lantern
But yeah! Traditional DBs already support this, if you consider this extension to be part of Postgres.
Literally. We do a lot of vector DB and RAG stuff (who isn't these days, right?) and after a bunch of testing and benchmarking went with pgvector integrated into our existing PostgreSQL database. Operationally simple, performs perfectly adequately. I'm sure there are some niche use-cases where the dedicated vector DBs make sense, but for anyone just getting into it, don't underestimate PostgreSQL and pgvector.
The "curation is an great addition to value" argument is certainly a powerful one.
I agree with the position that it makes sense to pay for a selection of writing (or other content) that someone, who truly deeply understands their demographic, puts together.
This site ( HN ) is certainly proof of that. It is effectively a magazine curated by its readers (upvotes/downvotes) for 'my deomographic' which is the demographic of everyone on here I guess.
In the novel "Fall", Neal Stephenson developed a theme I found profoundly insightful - the internet becomes a morass of trash so to get anything out of it, you gotta be selective about what you read or consume.
Selectivity, for characters in the book, was effected by subscribing to 'edit streams' - content pushed to them by editors who figured out what they should see for news and what they should see elsewhere from the arts, science, anything.
The super wealthy have personal editors - bespoke curated balanced content that was super expensive since one essentially is paying for person to "pre-read" and "grade" everything.
The 'middle class’ subscribes to one or more cheaper good shared 'edit streams' that had balanced and nuanced selection made possible by amortizing the cost over a ton of subscribers - a magazine.
Everyone else consumes what FAANG equivalents and bottom of the barrel anybodies pushes out for free on the "Your Feed" streams. Since they are free, you are the product.
Anything on those is largely driven by agenda - think "the right vs the left", propaganda, 'just because I have a mic", anarchy, pick your poison.
Two thoughts pop to mind out of all this
- just occurred to me that Facebook's / TikTok's /YouTube's etc "For You" streams are just really bad, (very addictive) very poorly edited magazines. Can't really make money from them because they are the equivalent of a old-timey pulp magazine.
- (this is the biggie) these FAANGs should set up some way for folks to make money through curation of their content (patented, TM, etc). Just send me a cash "Thank You" to cover college bills and the mortgage for this idea.
> these FAANGs should set up some way for folks to make money through curation of their content (patented, TM, etc)
Not sure what you mean by "patented, TM, etc". Other than that, I think this should already be possible from the outside e.g. by setting up a Patreon whose sole point is to provide a curated list of content from other platforms such as YouTube or Facebook, and already has a payment mechanism.
This hinges on the fact that content can be linked from the outside, but any approach will be subject to the mercy of the big platforms that host the actual content.
The "patented, TM, etc" was just a joke claiming credit for the whole thing to support the "pay me" joke in the next line. It is a completely content-free line.
The idea of doing a Patreon is interesting.
The real problem is that from a technology support perspective, this is not a real tech business, it is just a feature on any of the platforms. The moment they implement some type of "Magazines" on YouTube / Facebook / Tiktok, you gotta move from Patreon to their platform because of discovery.
The product is not the tech, it is the skill in curation.
As a curator, i could care less what the platform is as long as someone pays me as much as I can get out of the system. Happy to run it on multiple platforms, on email .. whatever mix pays me the most. But I realize right up front that I will have to be paid on the platform the content is on because that is where it will be easiest to get new sign ups.
On second thoughts, @moring, you are definitely on to something here!
It may be a product if one can find a way to effectively integrate content from across different platforms. Which means it has to be off any of the platforms.
Like, maybe, curated paid for lists of selected content via RSS, for my beloved, now dead but not forgotten, Google Reader
About user input, where the users can moderate contents by tools (like upvote/downvote).
I think that the user feedback is sometimes very dangerous. Corporation XY releases trailer, users do not like it. Trailer is review bombed. People running corporation are angry, they do not want downvotes.
There are several things that can be done to solve that "problem". For one: you can remove transparency. If things are not transparent it is easier to "fool" users, boost some things that should not be, or limit reach of things that are correct, true, but undesirable by the big tech.
I think that is the main reason why social media feels muddied, user input does not seem to matter that much.
It is hard to push content on mainstream media, if it is transparent that the quality of the thing you are pushing is mediocre.
I want search engines to operate similar to this. Instead of using googles monolithic index, you can subscribe to different trusted sources for lists of sites that are curated and maintained. Then your personal search engines queries them all at once.
I think if you could balance the incentives right it would put the onus on the curators to make sure that their indexes were full of high quality sites. And if one starts giving you rubbish, just remove their index from your search engine.
This is an interesting idea. The way I see it, there is a lot of really high quality content that does rise to the top of YouTube. But also the feed has a lot of recency bias. So a great creator who puts out things once every many months, ends up having their stuff at the top of the pile for just a week or two.
So as time passes, high quality quickly gets buried by the mediocre barrage of content.
So an interesting feed would have some dimension of time-indepedence.
I have, over the course of my career, found that the teams that tend to do this are pure-SQL teams ie in DB developers who spend all their time writing - and more importantly - reading SQL. Doing this actually removes a lot of debugging and code-fixing friction
Banks do not want to be in the news because they put someone on the street because of $100 or $500 or $1000 - the reputation cost is just too high.
Further, most banks will not sell debt under a certain amount., they plan for the losses, adjust for it in lending rates and just write off the debt as a loss.
You will see this in their annual statements as provision for credit loss (the planned losses) and net credit losses (actual losses). The amount for large banks is in the hundreds of millions and it is taken as part of the cost of being in the lending business.
There is, of course, some every fluctuating number based on the type of lending and amount, at which debt is pursued with vigor.
I was fortunate in that I, for the first part of my career, joined teams that were structured like this.
Some additional thoughts:
- keep things small at the start - task your team with at least two goals for the first 90 to 180 days
Then use the 90 to 120 days and the two tasks above to evaluate: - It is really critical that they be 'senior' people - 'senior' here meaning they have done and seen a lot. The title will not tell you if they are. You have to actually look at what they have done. Look for senior free-lancers with a variety of (longish 4 to 5 years) experience using a variety of technologies (C / Java / PL-SQL / Perl / Rust / C++ whatever etc etc - but boring old tech is better, you will eliminate another variable from your project complexity ) in variety of industries / verticals ( 3 to 5 industries. This is a signal of effectiveness at learning new things and delivering effectively in new fields with new people in new environments.- it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you.
- Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ).
- Key skills to look for in free lancers:
All the difficult stuff is going to happen in the background (batch processing, integration etc etc) so don't bother with front end development skills at the start - that is actually relatively easy to hire for.You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc).
- Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing.
- Plan ahead for what WILL go wrong. I strongly strongly strongly recommend reading two books
They deals with how executives and staff tackled a situation very similar to what you are dealing with and explains how to tackle some of the key structural problems you WILL run into. It is also a great resource for understanding how to run a project like this and understand how things could go right and more important, how things can go wrong and what to do WHEN they do go wrong (because they WILL ). The books will give you a very strong set of foundational thoughts about how to think about running this project if you decide to commit to doing it.