After a first video where Mihail tackled the ins and outs of working for a startup (which you can watch here), this episode is centered around coding for enterprise. Our colleague Robert shares his wisdom in the video below.
Our #frontendatbytex video series is a non-technical, friendly approach to development. We aim to introduce the new generation of developers to the world of coding for startups and enterprises, with snippets of our developers’ day to day activities. Have fun!
If you want to watch the whole series, you can do it here. Until then, here is this week’s video & video transcript.
Robert: ‘Hello! After last week’s video, where my colleague, Mihai, walked you through the Startup way of doing things, now it’s my turn to be the star and present you the key points of working on enterprise applications.
My name is Robert and in this video I’ll share my experience with working on enterprise web apps. Just like in our previous material, we’ll cover three main aspects: communication, project management, and coding.
However, the change in setting creates a shift in perspective. Keep watching to find out how.
As you already know, communication is a key component of all enterprise projects. Its implications are complex. Things tend to pile up, from setting meetings with the client (which, by the way, in my case is a substantial team of people) and keeping tabs on next steps, to proposing better ways of doing things and holding regular demos. When you add day to day activities on top of that, such as internal meetings, reviews, and research, you’ll end up with a mild case of the burn-outs. That is, unless you internalize the main rules of communicating with an enterprise client.
More often than not, enterprises prefer working with just one partner. That partner may come with both vast experience and its own team, which can help you speed up development and improve the code base, if that’s the case. From a time zone perspective, you won’t have to worry about syncing with four teams from three different countries. It’s just going to be your team, and the client’s. Although this simplifies the development process to some extent, it’s still essential to be proactive when it comes to availability and responsiveness. For example, on my project, there’s a significant time zone difference that needs to be bridged, so we make sure that for most of the day we overlap our schedules, even if that means not working the standard 9 to 5 hours.
When talking about cross-team communication, I do agree that being on the same page with everyone is crucial, but in an enterprise environment mistakes are less likely to happen. As things are more predictable than they are in a startup environment, ensuring that everyone is aware of the few changes that may occur is much easier, since everyone uses the same set of tools and abides by the same collaboration rules.
Now that we’ve covered communication, let me jump right into project management. This is pretty fascinating, and let me tell you why. So, we know from Mihai’s presentation on startups that an Agile approach is usually preferred, splitting the workload into sprints of one or two weeks, with planning at the beginning and a demo at the end. We do that as well, but depending on the project, sprints may be longer and cover either additional features, or rock solid stable ones.
For smaller teams, Scrum works amazingly. Daily standups ensure that everyone is up to speed on progress and impediments, and they can also reveal reusable components and better solutions, keeping duplicate code at bay. Retrospectives allow team members to identify what to focus on and what to avoid in next sprints, leading to better team efficiency.
The emphasis, however, is on the word small. Imagine a daily standup where over four hundred people share their progress. See my point? While Scrum works well for small teams, it might be a bottleneck for the entire development process if not done right. That’s why it’s essential to segment the team before implementing an agile approach to project management.
As a side note, the best thing about being part of an enterprise team is that all the development steps are predictable and well defined, which makes priorities unlikely to change as easily as they do in a startup environment. Developers who code for enterprises know very well where they stand, what they have to do, and what the next steps of the project are.
Lastly, let’s discuss what Bytex developers do best – coding. While our NDAs don’t allow us to detail the specifics of the code we’re working on, we’re excited to work with big clients, on even bigger projects. As the project remains structured and predictable, it’s important to note that there’s still room for proactivity. From small proposals, such as local refactoring, to big ones, such as core changes, they’re all welcome, as long as they are backed up by numbers and stats. The quickest way to earn the client’s trust is by being proactive. This can turn the partnership into a long term collaboration, so make sure to aim for that in your commitments.
When it comes down to code, you may have the chance to start a project from scratch, in which case I can only congratulate you! However, be mindful of the risks – one wrong decision can damage your entire project. That’s why it’s imperative to do the groundwork – be consistent in research, and only implement after you’ve done your homework. One key element worth mentioning from the previous ones is the code review. In addition to troubleshooting and improving quality, it also facilitates a great knowledge sharing opportunity, which allows you to continuously upgrade your skills, so don’t shy away from it.
This is it from my part! Now you know both the particularities of working with a startup and those of coding for an enterprise. It’s up to you to decide what kind of environment works best for your abilities. Join us next time, when my colleague Andreea will talk to you about working with remote versus on-site teams. Until then, don’t forget to hit the subscribe button and share this video with your friends. Bye bye!’