Hubble (https://hubblehq.com) | Python/ JS Engineers | REMOTE or ONSITE full-time | London, UK
Hubble is on a mission to find the perfect home for every company. We spend the majority of our waking hours at work, so it needs to be a place that we enjoy. So far, we’ve built an online marketplace to help businesses rent, manage and share office space in London.
We are backed by top venture capital firms Entrepreneur First, Seedcamp and 500 startups, and property tech specialists Spire Ventures (PiLabs).
As a product engineer you will have end-to-end ownership of projects, working on the full-stack to improve the Hubble platform.
The engineering team works closely with all areas of the business, so you'll be working side by side with product, design, marketing and sales to build the most impactful products. To do this, we balance building "hacky" MVPs with spending time to build highly polished products.
What sort of classes do you mean? Views? Models? Other? For us it hasn't changed much. Our apps were pretty self-contained so that splitting them into separate services isn't very arduous.
Stuff that is shared between apps is often related to 3rd party integrations, which could be moved into a separate (often asynchronous) worker/ service. In reality most of these design choices are done on a case by case basis, based on time/ cost/ maintenance.
It depends on what you're building. For us, we haven't noticed any issues with latency just yet and there are plenty of steps you can take to optimise this down the line.
As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often.
Perhaps the title was a tad flippant. You can use Django in a microservice architecture although if your services are small enough I would hazard to say that Django would be overkill for most implementations as it is not what it is designed for.
Saying that if it increases development speed and makes sense in the scenario then I wouldn't shy away from it.
I perhaps should have explained that a bit more. Technology choices have to make sense before implemented but giving developers the flexibility opens a lot of doors for creativity and exploration.
I strongly believe that learning new languages help people become better coders overall as it increases their knowledge of different problems and solutions which can be applied across most stacks.
Also no one developer should ever be solely responsible for a particular service. But that should also be the case for apps within a Django project.
Correct, writing code does not make money. However this change is a little bit like starting a blog... You don't see the immediate benefits straight out but you'll realise them over time. You can put it off and put it off but the longer you do the harder it gets, especially in this scenario.
This architecture doesn't make sense for everyone and we could have continued with Django. But making these changes now mean that we will be able to fix all the above a lot quicker going forward.
Not worrying too much doesn't mean not worrying at all! We still have tools in place to ensure silly mistakes aren't made or are at least rectified quickly. Just we don't expect 100% test coverage on every single feature or fix we ship.
This approach will probably change as we get larger but being a small development team means that it is fine for now.
True, but all these installed apps still increase the size of your one project which becomes larger and larger. You can't install it in parts, you can't make any architectural or language changes as it requires a rewrite of the whole project and each new release/ deploy effects the entire codebase.
Microservices doesn't fix everything and you're right about Django encouraging this type of design. Each approach has it's pros and cons.
We're lucky enough that we decided early enough for it not to be too big an issue.
Also we split up the re-write over stages and haven't done it all in one go. I'm gonna write more about it in another blog post but essentially we still have our monolithic Django system.
It currently powers the majority of the services except we have changed the architecture so we can split things out overtime. This allowed us to achieve what we wanted to in 4 weeks yet lay the groundwork for the future.
"What I was reacting to is what I hear relatively often - 'hey my house/room rent is X / m2, why can't I find an office for that price? It's just me and my buddy and we're broke and most likely out of business in 6 months, why don't landlords love us?'." - absolutely, I agree completely with you on that. If you can't afford it, you can't afford it.
We're not at all about making landlords turn themselves into co-working spaces.
We want to make renting office space easy.
At it's most basic distillation this means "search and transact" - matching supply and demand as best as possible. We believe this is broken due to assumed knowledge, market fragmentation and asymmetric information as mentioned in the blog post itself.
This not only improves the experience for companies looking for space, but allows those who own space to be discovered a a lot quicker. The very fact that zillions of craigslist clones already exist goes to show that this problem just has not been solved yet.
What we mean by Spacious helping liquidity is a derivative of search and matching supply with demand. If you are confident that you will be able to find a tenant quickly because there is a platform that exists to effectively match supply and demand, then you may have slightly less hesitancy in letting out your space to someone for <1yr.
Of course, I absolutely agree that common sense, and a typical risk / reward scenario means that you will always want to lock in a tenant for as long a lease as possible. This tenant would ideally have great covenants and >5yrs of financial history.
The point I was referring to in my initial response was to the no. of companies now springing up that need <1yr leases because of uncertainty and how a space owner may benefit from that... whether this is from co-working or subletting if you are already a tenant.
Your insight is very much appreciated and I really do enjoy discussion around this!
Absolutely, this is the norm rather than the exception. However, asymmetric information only works as long as most parties in the market are acting in this way. As soon as people start being more open, this changed the landscape very quickly, which is what we are seeing in London.
If the market does indeed stay that way, rather than wasting time talking to individual spaces we are working on technology that should be able to inform all those with space (even if they keep the price hidden) of search and budget requirements of a potential. This should at least open dialogue.
Absolutely agree. There are still plenty of companies out there who have the relevant covenants and ability to sign that 3 year lease.
However, as the economy evolves and high growth companies companies become the norm the number of people willing to commit to a 3 year lease will start diminishing. This not just because they are not able to forecast their financials, but they are not able to forecast their staff numbers either.
It's an interesting time for commercial property and it'll be intriguing to see how this plays out.
Completely agree. At the end of the day markets depend upon supply and demand forces. The economic landscape looks much different to what it did 10 years ago. Smaller companies that need contract flexibility are springing up everywhere, and the demand for flexible space is increasing. There's only so long this can be ignored by those operating or owning commercial space.