Here I’ll discuss a few notable things I learned (that you will probably find useful or relevant to your own career development,) during the year I spent working for Ryan Brandt and Michael Diego on Wise software projects.

As with any opportunity in life, you get out what you put in, and I was lucky to have such a singly-motivated team to work and grow with.

How I Got the Job

In short, I found the company on AngelList and replicated their tech stack.

At this point in time, it was looking like I wouldn’t have an internship for summer, as despite my EB¹ experience, I had received hundreds of rejection emails and messages, including companies I had previously worked for.

While I never really thought or asked about the candidates who didn’t make it, I blew the socks off my interviewers by taking what I knew about their tech stack and deploying a minimum-viable version of the thing, demonstrating that I could set up and use everything they listed: Heroku, Django, and React.

Demonstrating that you can quickly learn the basics and compose the parts of the tech stack a startup is using is a surefire way to say “I’ll be useful!”.

Get a Mentor

Did this ever change my life; at Wise Assistant, Ryan² and I worked together to build out the backend. When our lead frontend guy left to become a Chocolatier, the frontend also became our responsibility.

“A good mentor is worth 10 college educations” ³

At my previous internships⁴¹, I was either too inexperienced, afraid, proud, worried about wasting the time of a busy superior, or arrogant to get a lot of hands-on, direct help. At a startup, you become too essential not to help, provided you put in the time to learn and aren’t asking lazy questions. During my first two months at Wise, working online, I probably put in ~10h a day of struggling, then succeeding, to make useful changes to the codebase. I was still learning Django, but Ryan² was willing to put in plenty of time to discuss my proposed solutions to the problems I was assigned.

As a result, I learned an incredible amount in the first two months, and I was able to become a very useful tool and conversational sounding board for my manager.

Talking to someone every day, you tend to learn how they think, and Ryan² and I were able to almost telepathically broadcast large parts of our conversation, make tons of assumptions, and only talk about major sticking points.

All in all, my working relationship with my manager helped me grow dramatically as a developer. I was handed down many hard-earned lessons, and in return I did my best every day to get stuff done!

Enjoy a Parallel Universe or Two

While working on the Wise backend, I also started a software project for IEEE uOttawa called Democracy, which I wrote about here. I was able to utilize all the skills I was acquiring at Wise and become the mentor and manager for somebody else, allowing the skills and knowledge to flow down from my mentor to him, like a waterfall.

Eventually, I was also able to take lessons and patterns I had learned while building my own product, and integrate those patterns back into the Wise app.

In addition to this virtuous cycle, I also ended up using React for personal and open source projects, and that experience resulted in a similar feedback loop.

You must be cautious when operating on multiple similar parallel projects, but it was certainly interesting to use the same tech in multiple different scenarios at once!

Beware Knowledge Silos

The frontend developer that left halfway through my tenure was highly productive.

What he left behind, though, was a finely woven web of abstractions that nobody else on the team wanted to take the time to understand and extend. As a result, we only copied his work, and built around it, but never took the time to extend or improve it. It fossilized and became part of the bedrock of the app, never to be touched again.

I did not understand the state management code. The other frontend developer on our team, a skilled visual designer (though more web developer than programmer,) had worked with the lead developer since the beginning of the project, and he did not understand the state management code. My manager did not understand the state management code.

The real lesson for me was this: It doesn’t matter how efficient, fancy, or cool the code you write is if nobody else understands it and you do not transfer or document your knowledge.

Tragically, this led to multiple other state management tools being used, according to the developer in question’s preferences, and that aspect of the project becoming inconsistent and varied. It was only as I approached the end of my time at Wise that I began to dig into and understand the libraries we had buried.

Write as little code, and as little fancy code, as possible.

Working with Opinionated People

There’s a reason why so many interviews end with rejection: personality really does play a large role in the cohesion of a team. If you’re spending a lot of time with a small set of people, the little things do matter, and the ability for a manager to balance conflicting personalities on a team is a golden skill.

I myself, for better or worse, am an opinionated person. The classically blunt, matter-of-fact, no respect for weasel words engineering mentality seems to exist in me naturally, and has gotten me in trouble a number of times.

If engineers are in agreeance on the fundamentals of how a project should be completed, they go together like apple pie and cheddar cheese, but this note is a short story about how the opinions on the following can clash, and how our team resolved them:

• Communication volume, style, and tone
• Volume, quality, location, and style of project documentation
• When to bend and break project programming conventions
• What those conventions ought to be/establishing new conventions

In short, usual solution was compromise. Something or someone needs to give way. As a green developer, I would only ever listen and nod, wanting to learn as much as possible. A few months in, though, and I was starting to question the usefulness of additional work another developer was completing himself, and asking others to complete. Let’s call him Developer V.

Developer V was a big fan of what he called overcommunication, and though I found his feedback very useful at first, it grated on me as time bore on; it seemed everything I committed was meticulously nitpicked and rearranged, especially the docstrings and comments that were included with the code.

I need to stress here that V did provide plenty of very useful feedback and did help me grow as a developer. The core conflict here was verbosity.

V was the only member of the team who expected the project documentation, comments, and PR discussions to be meticulously detailed. At the end of the day, my own conflicting opinion (I prefer conciseness,) sowed a lot of discontent on the team, and in the end I would typically accept his changes with no discussion on the basis that arguing was pointless.

This took a toll on Developer V, and I’m sure he left Wise in part due to my involvement in the project and the essays he wrote while reviewing my work.

The Importance of Product Validation

Yes, here’s an obvious one: Reality will shatter your dreams, especially if you don’t do your market research!

Wise had a dramatic pivot after I had worked there for a few months. This is not at all uncommon for a startup, as many will pivot as they struggle to find market fit and a path to sustainability.

In short, we didn’t do enough market research and product validation, which led to the first platform we built not being picked up by the target market.

For many team members, Wise was startup experience number one. My manager, CEO, and peers all had lots of previous industry experience, but that didn’t save us from creating a product which was fundamentally unwanted at the place and time we had deployed it.

Here’s the silver lining: This first failure granted the team insight into the importance of market research, and when our targeted American cities began to open back up, we had built a user base and a compelling platform that met the needs of our target audience far better than our original app.

Validate ideas with your target users before investing your time and money.

Startups vs Consultancies

A Startup is a very small company assembling a novel product or service.

A Consultancy is a large company with teams of varying sizes, completing technology work for payment, creating new or improving existing systems.

Both:

1. Have tight deadlines and, if mismanaged, crazy crunches.
2. You work on a project with a small to medium sized team.
3. Your performance truly matters, and dead weight will be let go.

They can be equally hectic, and as far as I can tell, the risk and reward of working at a startup boils down to a few things:

1. Startups are far more open to novel solutions to problems.
2. You will learn a far greater variety of things at a startup.
3. Being “the man for the job” and finishing features (or even entire systems,) with minimal management overhead and planning is highly valued.

The undeniably huge benefit of startups over consultancies and enterprise product development is what I’ll call absolute flexibility. You can work as much or as little as you and your manager agree, as long as your net productivity is satisfactory.

If you’re having a horribly sh*t week, it’s possible at a startup (as long as your rapport with your manager is great,) to take the rest of the week off to try and reset and get back to normal.

With a PTO / sick day system, this requires a large amount of painful-to-write emails to the administration, so much so that it’s probably better just to come in to work and go through the motions (pretend to work, and probably get 1h of normally productive work done all day,) than to try and take time off.

This admittedly high level of managerial trust is something that I’ll miss as I head into the enterprise for a few years.

The Omnipresent San Francisco Startup Culture

(No, that’s not a Red Hot Chili Peppers album title/ indie band name.)

I was lucky be involved in this scene, albeit from a distance; San Francisco is truly the heart of startup culture, and the vibes and values of the city seem to permeate all companies, including Wise.

The reasons could be debated, but I assume this is due to the very large network of designers, innovators, programmers, and entrepreneurs all working in close proximity, along with the naturally higher number of social interactions had by those who frequent The San Francisco Bay Area.

Companies in San Fran seem to be prone to mimicry, from the Big Tech Art Style being used everywhere to the pastel pallets, abundant emoji, apple worship, and rounded user interfaces, with Wise being no exception.

Resting on these prior field-tested aesthetics and innovations, and being at the bleeding edge of startup culture, does seem to have a number of inherent benefits, including a built-in audience who appreciates the look and feel of the San Francisco technique.

Exactly how much it helps is debatable, but I would argue that conforming to these rules does allow the development of the UX to focus more on features and composition rather than the fundamental style.

If you do become involved in a startup, chances are high that you will be directly or indirectly immersed in this culture.

Recommendations

All the members of Wise who I worked closely with (and stuck around for the journey until I left,) get my unwavering recommendation for others to hire. We were a hardworking team, and though I’ve left, I’m hoping to see the product continue to evolve and become more popular. You can check out the company on LinkedIn .

1. Ryan Brandt , my manager and the CTO
2. Michael Diego , product manager and CEO
3. Nattawod Satee , design and web development
4. Kevin Solorio , design and marketing