Until a few weeks ago, I had no idea what exactly a full-stack engineer was, let alone what the role entailed. I know, I know – I work for a tech startup, I should know these things.
You’re right; I should.
So, to educate myself, I sat down with one of Process Street’s engineers, Herbie Porter, to discuss what he does, his first year at Process Street, and the art of making pandemic cocktails:
- The very distinguished Mr. Herbie Porter
- One year ago today…
- The makings of a programmer
- Shape Up with Process Street
- Essential tools for the discerning engineer
It is my privilege to introduce you to…
The very distinguished Mr. Herbie Porter
Q: I guess the first question is: Who are you? What are you passionate about?
That requires some self-reflection I wasn’t quite prepared for. [laughs]
Who am I?
I’m a problem-solver at heart. I’ve been working in software for over a decade now. I love to build things and challenge myself, which particularly suits me to software development. 
“I’m a very lucky person who gets paid
to do what he loves to do.”
I joke with my friends that I’m getting paid to do what I’d be doing anyway. If I wasn’t getting paid to write software, I’d be doing it as a hobby in some form. There’s a famous quote by Mark Twain: “Find a job you enjoy doing, and you will never have to work a day in your life.” I think I’ve been really fortunate to have found that.
And so I guess – who am I? I’m a very lucky person who gets paid to do what he loves to do. I generally just love to build stuff and fix things. I like learning things, really.
I really enjoy cooking, reading, and being outside in any form really – hiking, chilling at the beach, camping. My recent project has been making cocktails, which has worked quite well with the pandemic, being stuck at home.
We also love to travel, which fits very well with Process Street. My girlfriend Maria and I have been to Thailand and South America a few times. We’re hoping to live in Spain for two months at the end of this year and work from there. Fingers crossed that still goes ahead!
Q: Are you both remote or is she “pandemic-remote”?
[laughs] I like that. She’s pandemic-remote. She does work for an American startup, but they’ve got an office in Brighton. She used to work in the office, but now, she’s 100% remote. I’m not sure what they’ll do post-pandemic.
Q: It’s nice having a little bit of career overlap with your partner.
100%. We can talk shop and we understand each other. We’re in slightly different areas of tech, but it’s similar enough to be able to really connect with that, which is really fortunate.
“Engineers without direction –
we’ll just build anything.”
It’s nice to get that empathy and understanding. We can bounce ideas off each other. Especially during a pandemic, your main support structure – if you’re in a relationship – is your partner.
One year ago today…
Q: Did you work in a remote company before or this is your first remote position?
This is my first gig. I’ve worked in lots of different industries all over the UK, but mostly it’s been London and the Southeast.
My last gig came to an end and I didn’t want to commute to London. So I started looking at remote gigs. Obviously, I found Process Street. I got really excited about what they’re doing, the technologies they use, and being able to jump on that. And I haven’t really looked back since. It’s great.
“At Process Street, we’re building everything
from scratch. Everything’s new.”
And it also came at the perfect time because I secured this job a month before the pandemic hit, so I already had a fully-remote gig. [laughs]
Q: Did you know about Process Street beforehand or did you find it during the job search?
It was completely random, actually. I found it on Stack Overflow, which is a forum for developers. And I did a bit more digging into the company and liked what I saw.
Most of my experience has been with bigger enterprises, companies like JP Morgan where you’ve got over 250,000 employees.
Whereas Process Street is a small, scrappy start-up, trying to get first-to-market with a no-code workflow solution, and making a name for themselves. So I thought that’d be really exciting. It was a bit of a change for me, but something that really appealed to me.
Q: What’s your experience working at a start-up been like, as opposed to a bigger company? Is it what you thought it would be?
It’s roughly what I expected. One big difference is how the teams are structured. In a big enterprise, a technology team would have an engineering manager, a couple of designers, some backend developers and frontend developers, maybe a database developer too.
“In three weeks we
rolled something out
that’s going to
fundamentally change
our users’ experience for
the better.”
Here, we’re quite lean. We’re still growing as a team. You work in a small squad and without the more traditional roles so you end up wearing a lot of different hats, which I like.
One other thing I love about working for a start-up is you get to solve all the problems for the first time.
Say you get hired by a company and you’re working with software that was written 10 years ago. You’ve inherited what we call technical debt from that bit of software. It might not be perfect. It might have bugs. It might have its idiosyncrasies and that makes it hard to work with.
But at Process Street, we’re building most things from scratch because we’re a start-up, and everything’s new.
The makings of a programmer
Q: Did you always know software development was a direction you wanted to go into?
I always kind of knew it.
My uncle works in IT. From a young age, I spent a lot of time with him. I’d help him build computers and things like that, and I thought it was cool. So that was when I was about 12 or 13. Then, at school, about 14, we started to do some very simple programming.
There was this application called Turtle Paint. We programmed this little turtle to go around the screen and draw things. Super simple, but you could also do some quite complicated things with it.
That’s when I fell in love with programming. I had this vision of what I wanted to create. It was up to me to solve that problem, describe it, and write instructions that the turtle would be able to follow.
I find that very rewarding. I think in the same way a carpenter or sculptor would feel about building something with their hands. A programmer gets to build something with their minds and their keyboard.
“I had this vision of what I wanted to create.
It was up to me to solve that problem.”
It’s the same reward cycle if you design something. You envision it, visualize it, and then you build it.
There are times where it’s frustrating. It won’t work for two days, then when it does work, it feels amazing. For me anyway. [laughs]
Q: How did you end up being a full-stack engineer?
I’ve bounced around. I spent five years as a backend developer. I did a couple of years of frontend, and now I look for full-stack roles because it’s exciting. I get to be a bit of a jack-of-all-trades.
One day I’ll be optimizing our database to make it go faster. Another day I’ll be working on a new frontend feature like global search, which we just released. It’s really exciting. You get to learn lots of stuff and work on different things. That means your workweek is really varied, which I like.
Shape Up with Process Street
Q: So let’s go back to your first few weeks at Process Street. What was your impression of everything?
It was a new experience for me. This was my first remote gig, so I was used to being in an office and sitting behind someone for the first week to get onboarded. That’s the normal onboarding flow for a developer; you pair with someone and they show you the ropes.
But I think the way Process Street has done it is really good. The company’s been remote for five years, so it’s not a new thing. A lot of the kinks involved in supporting a remote work structure have already been ironed out.
So my first week was spent going through Process Street checklists to get everything set up. At Process Street we use our own software to onboard new engineers, so that meant I was able to really dig through our own application and see how it worked.
That went very well – and surprisingly easy, considering some places that I’ve worked it can take you a long time to get set up.
“We’re trusted to do have control over what we work on.
That’s amazing.
A lot of companies don’t have that.”
It was during that first couple of weeks that it clicked for me that this is a great tool. It’s solving a need the market doesn’t know it has yet. And that’s a sign of an amazing start-up.
Q: How long did your onboarding process last? At what point did they set you loose?
When did they let me break stuff? [laughs]
I think it was about a week to two weeks. The first week was purely onboarding. Then the second week – we use Jira tickets to track our work – I started working on my first tickets.
At the same time, I worked with Tarik [Ameen-Ali, Customer Support Manager], who took me through the Customer support training. That’s another thing I really liked about onboarding, which I forgot to mention. You work in Customer Support for the first couple of weeks. So you man Intercom for two hours a day, and actually get to speak to our customers and fix the issues they’re having.
“We want to release stuff that our users love
and makes their lives better.”
That was really invaluable to get a sense of what our users need, and the problems they have. This directly feeds into my ability as a developer to make their lives easier. Within a week, I was working on something and delivering small improvements for our users, which was really nice.
Q: Does the work still vary like that? What would be an average day or week for you?
It does vary, but that’s mostly around my life. Normally I start around 9 or 10. Check Slack, check email, get up to date on everything, and then do peer reviews.
(Every bit of code we write is reviewed by another developer to reduce bugs and improve quality.)
Once I’ve done all that, I normally have about four or five hours of focus time when I’m coding my current ticket or feature. Then I normally have two hours or a couple of hours of meetings in my afternoon/evening.
That’s my average day. The week varies, too. For example, this week, [my girlfriend and I] are trying to sell our flat, and this last Friday, I spent half the afternoon tidying my flat for viewings. So I shifted my schedule and made up the hours on Sunday.
And that’s really nice. As long as you’re around in that cross-over time when there are meetings, the rest of the hours are pretty flexible. Sometimes I’ll take long lunches, go for a walk with Maria, or if I need to go to the dentist. It’s really nice to have my workday work around those things.
Q: What tools does the development team use on a daily basis?
In terms of tooling, we try and leverage SaaS wherever we can. A lot of companies will try to build it themselves, but we prefer to focus on our core product and leverage open source software or Saas products where we can. We use GitHub to store our code. We use Slack for communication. Everything happens in there. We use CircleCI to build and deploy our code.
Q: How does the development team work? Do you get assigned a whole project to work on or part of a project?
We use a methodology called Shape Up. The way Shape Up works is you split your time into chunks. We split it up into eight-week chunks, and that’s called a cycle. Inside each cycle, we spend six weeks building something. Then you spend two weeks on what’s called cooldown, which I’ll cover later on.
The six-week cycle is where we actually build the majority of our features. Ryan [Scheuermann, Director of Engineering], Cameron [McKay, CTO], and Michael [De Souza, Principal Product Manager] will put together ideas into a pitch. Then they’ll pitch all those ideas to a committee, that includes Vinay [Patankar, CEO] and other senior stakeholders. Based on the pitches, the committee chooses what we work on each cycle.
“We trust our engineers enough
to give them two weeks every 2 months
to do things that they think
will benefit our users.
That’s really empowering.”
So, before the cycle starts, there’s loads of ideas that have come in from various avenues, whether it’s Customer Support or the product team. Michael, Ryan, and Cameron will triage those ideas into pitches. Those pitches will get voted on and then the chosen pitches come into the cycle for the development team to work on.
This cycle, my squad was given three pitches to work on. We work on that pitch from end to end. That’ll be a whole feature, for example, global search or the Slack app. We work on that whole pitch, that whole feature for a couple of weeks. And at the end of the cycle, hopefully, it’s ready to go out in front of users.
The little bit at the end of the cycle is called cooldown. It’s quite novel. It’s basically time for the developers to focus on things that they think are important. That doesn’t sound like a big thing. But in software development, it is a big deal.
There’s always pressure to get new features out as quickly as possible, so developers don’t necessarily get time to improve the codebase or tidy things up, or improve performance. That’s what cooldown is for: so the developers can work on things that they think are important. I like to think of it as a two-week Hackaday.
Hackaday is basically a time for developers to come up with ideas and do their own thing, or fix things that they’d like to fix. That’s a big differentiator for Shape Up, and also for Process Street. We trust our engineers enough to give them two weeks every 2 months to do things that they think will benefit our users.
That’s really empowering and really nice to have that trust and autonomy.
Q: Are there some things you’ve developed during cooldowns that have made it into Process Street features, or will potentially become features down the road?
I’m trying to think of what I’ve worked on in the last six months. [laughs]
We’ve only done one cycle so far; we’re brand new to Shape Up. I probably should have mentioned that. We’re still learning it.
I spent most of the last cooldown restructuring the template dashboard. So I adjusted that so you could rearrange your columns and resize them, and have that view saved.
I wrote a whole load of performance improvements and refactored the code to support our users completely customizing that view. That was an idea I’d had a couple of months ago. I’d put it on the back burner of my list of things to do, so when the cooldown came up, I decided to work on that.
Q: This is really two questions. What is the most challenging part about being an engineer? And what is the most challenging part about being a remote engineer?
I think the most challenging part of being an engineer is staying focused and knowing what to build. Because engineers without direction – we’ll just build anything. [laughs]
But using Shape Up, and having great product people like Michael and Ryan direct our building helps that.
“It’s quite common to get into a
room together for a few hours and hash it out.
You can’t do that being remote.”
We do try to make data-driven decisions. We’re always collecting feedback so that when we work on something, we know it’s going to be something our users will like.
I think what’s challenging as a remote engineer… I think it’s the same for any remote employee.
The dynamic is different. You can’t sit with people.
As an engineer, especially, when we’re going to solve a new problem or design a new feature, it’s quite common to get into a room together for a few hours. Have some coffee, maybe get some donuts, have a big whiteboard, and hash it out.
You can’t do that being remote, so we have to rely on tools like Miro – which is a virtual whiteboarding tool – to simulate that experience.
I think we’ve done a great job of trying to simulate that, but it’s never quite going to be the real thing. I think in-person problem-solving is what I miss the most.
Q: We’ve recently released several new features. Can you go over them a little bit, or tell me a bit about your favorite ones to work on?
We just finished the new global search, and that was super exciting. In three weeks we managed to roll something out that’s going to fundamentally change our users’ experience for the better.
It’s such a small thing, but being able to search your templates in milliseconds from anywhere in the app is probably, for our users, game-changing. And we managed to do that really quickly and to a really high standard.
Q: It’s been a game-changer for me, too. I appreciate it very much. Thank you.
[laughs] No worries!
Without getting into too much detail with it, we used a SaaS provider called Algolia to help us with that.
That meant that our time-to-market was really short. We leveraged our connection to Accel, our investor, who also invests in Algolia. It was really nice to have that family of start-ups helping each other out so we can deliver value to our users quickly.
Global search was really, really cool. I’m really looking forward to getting that in front of users and hopefully getting some positive feedback.
A lot of companies might spend a couple of months planning a project like that, but Shape Up encourages short, concise periods of time to solve the problem quickly and get something out. It might not be perfect, but you can iterate on it later on.
“Re-architecting something like that
is complicated and it’s high risk.
But to be able to do it,
and really improve the performance,
with zero downtime –
I was really proud of that.”
The other thing we’re working on at the moment is the Slack app.
Again, it’s not an incremental change. It’s something brand new. I know for myself, I live in Slack. The more I can do in Slack, the easier my life is. So being able to release something like that, and make our users’ lives better is a huge drive for developers. We want to release stuff that our users love and makes their lives better.
I think global search and Slack will both do that, so we’re really excited to see them go out.
Q: So what advice would you give to a new remote worker, or somebody considering going into or taking a remote position? What should they know before they jump in?
Either have a separate office, or get a coworking space.
I’m at home at the moment because of the pandemic, but I had a coworking space very early on. That made a massive difference to my work/home life balance. Now I’m working in the living room, so it’s very hard to differentiate between work and home. If you don’t have a separate office, definitely get a coworking space or somewhere that you can go and separate your lives.
“Taking time to build those relationships helps
your teams are more cohesive and
you work better together.”
The second thing is really to invest in building relationships with your colleagues. That’s going to be harder because you’re not sitting next to them. You can’t go out for beers on a Friday or grab dinner when it’s someone’s birthday.
At Process Street, we have different social events – “donuts,” for example. Each week we get randomly paired with other colleagues for a purely social virtual meetup. It really helps build a sense of community, and gives us a chance to get to know colleagues outside our immediate teams – people we’d normally run into organically in an office situation.
Investing in those activities and taking the time to build those relationships helps you become a more effective engineer because your teams are more cohesive and you work better together.
That’s hard with remote work, so you do have to really invest in that.
Q: You just celebrated a pretty significant milestone: one year at Process Street.
I did, yeah. It was around last February when I started.
Q: What are some things you’ve done this year that you’re the proudest of?
Good question. I’m proud of lots of things. Global search is a massive one. I think the way that came together is amazing. To a non-techy, having some millisecond search maybe isn’t that impressive, but to an engineer, that is like, wow, that’s really, really cool.
Another thing I did about six months ago was to redesign our architecture front for static asset delivery, which basically means I made the website load faster.
By leveraging various other services, and software providers like AWS, CloudFlare, and caching, we were able to substantially improve performance for our users around the world.
Our servers are in North America, so if you’re in North America, you’re going to get a great experience. But we have a lot of customers in Europe or Australia, and their experience wasn’t as good as we wanted it to be.
That’s something else I’m very proud of because re-architecting something like that is complicated and it’s high risk. But to be able to do it, and really improve the performance, and to do it with zero downtime – I was really proud of that.
Q: Last question. What are you working on right now? What are some things that are down the road for Process Street?
I don’t actually know what I’ll be working on next, because of the way Shape Up works. We haven’t started the next cycle yet, so the pitches haven’t been voted on.
“And I haven’t really looked back since.
It’s great.”
I think we’re going to be working on a [knowledge management system]. So what that means is we’re going to be – not necessarily pivoting – but changing one of our key features to support more of a static knowledge base type use case, because a lot of people come to Process Street thinking it’s about documenting processes.
And it is. But up until now, we’ve really focused on making those processes dynamic. So being able to run a checklist, assign it to people with form fields, etc.
But a lot of people just want to be able to build their processes as a static thing, and we haven’t necessarily catered to that use case. That’s something we’re going to potentially be looking at over the next six months, catering to the static workflows/knowledge base type use case.
I think that’s really exciting.
Q: I’ve kept you a little longer than I was supposed to, so before we go, I’ll just open it up. Is there anything you want to add about working for Process Street, in a remote company, or as an engineer?
We talked about a lot of them already, but I just want to highlight a few things that I think will really stand out to engineers like me, reading this, and potentially looking to work at Process Street.
Two of our values are to act like an owner and default to action.
We talked about that a little bit, how we’re trusted to do the right thing, and given a lot of autonomy and control over what we work on. That’s amazing. A lot of companies don’t have that, but Process Street does.
The work is very multifaceted, so that is super exciting. And it also means you get to learn a lot of stuff, because we’re building all these things from scratch. Since I’ve started, I’ve learned three or four different new technologies. And that’s, again, really appealing to engineers. Engineers love to learn new things. They love to be trusted to do the right thing.
The last one is Shape Up. It’s a relatively new thing in the industry but it is making some waves. If you’ve heard of it, you’re probably like, that’s really cool. Definitely a selling point for engineers.
“At Process Street you get autonomy, trust, lots of learning, and an exciting day-to-day life.”
Essential tools for the discerning engineer
What’s your go-to cocktail? Give us your recipes in the comments below!
The post The Inside Secrets of a Process Street Full Stack Engineer first appeared on Process Street | Checklist, Workflow and SOP Software.
0 Commentaires