Hello everyone and welcome to the Sprkl tips & tools series! Our series features conversations with prominent developers, exploring topics around developer productivity and modern software complexity.
This time, Allan Bogh, a senior software developer, shared valuable insights on enhancing the productivity of developers dealing with complex software environments. We have some exciting insights into the development processes at Disney, Uber and Tesla for you.
Developers are the backbone of any software organization, responsible for designing, developing, and delivering the products that determine the company’s success. They are also the most expensive and scarce resource of any software company. It is vital to prioritize developers’ satisfaction, well-being, and productivity. In addition, ensuring that they can work efficiently when dealing with software complexity and dedicate their time to developing the product rather than solving issues is crucial.
After college, I interned with Weyerhaeuser, created an MLS search website for a RE/Max franchise office, and then worked for Disney.
At Disney, I started as a contractor on their Disney ID team, helping their consulting team to create a proof of concept single-sign-on website. Their team struggled with making it work, so I proposed an iframe postMessage solution and threw together a PoC in a night or two. About a week later, the consulting company was dismissed and I became the lead developer for a team of 8. We had 3 months to create a single-sign-on website using iframes which worked in nearly every browser. You can still see this website on ESPN.com when you log in.
After Disney, I landed at Uber, where I worked on an open source project called react-digraph and led an internal project team. I also advocated the switch to Typescript, although Uber was heavily tied up in Flowtype to the point of anger if you even mentioned switching to Typescript.
After its IPO, Uber’s growth had floundered, and I couldn’t see much upward growth in my career, so I decided to jump ship and try my luck at Tesla. This was probably the worst decision of my life.
I worked for Tesla as a remote employee during the pandemic on an internal project called NetworkMaps. This tool is used by the Network Operations Center (NOC) and planning team to see the status of the charging network as well as plan new supercharger locations.
“After exactly a year at Tesla, Elon sent out a famous email regarding remote workers and, within a week or two, fired thousands of employees. I am now caught up in a lawsuit regarding how they didn’t follow the WARN act.”
I’m now contracting again and working for another fortune 500 company, which I won’t disclose or reveal any information about their technology.
R&D teams dealing with software complexity
Some companies have clear boundaries between Dev, QA, Backend, Frontend, DBAs, DevOps, and the various levels of managers; while other companies maintain a flat structure of Devs and Managers, where devs perform all of dev, QA, DBA, and DevOps work.
A traditional company with clear job boundaries was Disney, which had a waterfall release mentality, while Uber is a flat structure with an agile release process. As a person who prefers standards, I liked the structure of Disney’s development teams, but I preferred the freedom of Uber’s development practices.
Most of my teams were below 20 people, although the larger org sometimes had 30-40 people and contractors. Disney had a concept of very few full time employees to a high number of contractors, whereas Uber had a meager contractor count compared to its FTEs.
Software complexity: Challenges and improvements
I’ve worked in many codebases with ranges of complexity. I won’t speak about my current codebase, but I think the answer to this question is that each year codebases get a little more complex. This isn’t only a reflection of my age but a hint at the growth of complexity of frontend development.
Development processes & methodologies
As much as Agile has been bastardized by the project management process, I rather like the idea of Agile’s Release Early, Release Often (RERO) clause. It allows developers to create code, make mistakes, iterate, and release new features and bug fixes quickly.
I’ve learned that most companies follow a different development process, some using a waterfall technique, some more agile in nature. There’s no definitive answer on which one is best for each company or project; it all comes down to your project’s popularity and whether you can afford downtime or better tooling if something goes wrong. The waterfall approach focuses on better testing before releases while the agile approach focuses on fixing issues as they develop, essentially eliminating the QA team and making all developers into test writers and the public becomes the beta testers.
Feedback & testing
Feedback is usually given in the code review process once a PR is generated and the team is notified. It’s up to the developer to request meetings with project managers to gain feedback earlier. The key to getting better feedback is to make smaller PRs.
It’s best to perform testing at all stages in the lifecycle. Developers should create unit tests to run locally. Those tests should run successfully before a commit unless they’re intentionally skipped. Linting should also happen locally as you develop. It’s best to set up your editor to automatically check the code upon save. Eslint can be set up with Prettier to automatically format your code on save, ensuring that all developers use the same standard throughout the organization.
The PR should run the unit, and integration tests, including code quality checks. If there are pre-prod e2e tests that can run, then the PR can also run those, although it may be better to run those in a validation environment that uses production data.
Debugging & Observability
If there’s a bug report that I’m working on, I usually find the component causing the issue and use console.log and the browser’s developer tools to trace back where it came from. This is an old technique from when there were no developer tools like we have today that I never grew out of. Sometimes I use the debugger and can pause the code and other people use react devtools or redux-toolkit, but I rarely use those.
I kind of hate the idea of measuring developer productivity because it makes people hate their jobs. Sure you want to see story points moving and tickets closing, but if the person is miserable then it infects your workplace and makes them want to look elsewhere. I prefer to instill a desire to build solutions to problems, where a developer can invent a solution rather than only pushing out code. When a developer implements a new solution that saves days of development time, the whole team’s productivity goes up.
What is Sprkl
Sprkl Personal Observability platform can increase your productivity by allowing you to immediately see the impact of your code changes on the entire application. Sprkl provides developers with the feedback they need as they write their code. When working with Sprkl, developers do not need to use logs, debuggers, or linters, as they instantly receive the feedback they need while writing their code in the IDE.
Give Sprkl a try; it’s completely free: Start here
Enjoy your reading 11 Min Read