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.
Key Takeaways
Software orgs & Team structure
Flat companies conflated the idea of “Full Stack” to mean “everything and the kitchen sink” when it was originally intended to mean Javascript frontend and backend using Node.js.
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.
Disney, a traditional company with clear job boundaries, had a waterfall release mentality, while Uber is a flat structure with an agile release process.
Managing software complexity
Developers used to develop websites with static files or server-generated code from PHP. The most complex aspect was wrangling CSS styles. Now we have to know Javascript, CSS, CSS-in-JS, JSX, the DOM, Node.js, Express, GraphQL, REST, databases (all of them!), GoLang, Python, maybe even Java, React, Redux, Typescript, Babel, Webpack, Eslint, and Jest.
Each year codebases get a little more complex.
Backend engineers are afraid to get into frontend development because it’s daunting; it’s insane that it’s gotten this complicated. Take me back to the good old days of JQuery and IE5 issues.
Development processes
Agile has been bastardized by the project management process; I like the idea of Agile’s Release Early, Release Often (RERO) clause.
The waterfall approach focuses on better testing before releases, while the agile approach focuses on fixing issues as they develop, eliminating the QA team and making all developers test writers and the public the beta tester.
Automation. The more you automate things, such as CI/CD, the more time you have to solve problems.
Testing & feedback
The key to getting better feedback and improving development processes is to make smaller PRs.
Perform testing at all stages in the lifecycle. 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.
Set up Eslint with Prettier to automatically format your code upon save.
Ensure 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.
For bug fixing, find the component causing the issue and use console.log and the browser’s developer tools to trace where it came from.
You can use a debugger, react dev tools, or redux-toolkit.
Here are 4 general tips on enhancing the productivity of developers dealing with software complexity
Be helpful. Other developers don’t know what you know, so you can use your experience to teach them. The more they know, the better off your team is.
Listen to music to get into a zone. The rhythm will help guide your brain to answers. Here is my playlist if you want to check it out. I was in high school in the 2000s, the best years of Alternative Rock, so most of my music is in that punk/alternative genre. I also like fast-tempo music for running or upbeat music to help me feel better.
Take breaks when you reach milestones. Don’t push through to develop the whole solution at once; take a break every once in a while to think about the problem and plan the next development phase. This “take breaks” should also imply taking a vacation every once in a while.
When you don’t have an answer to a problem, ask others for help. Even getting on a call to someone to explain the problem can give you a solution. If you still can’t find a solution, then sleep on it, and you might have it when you wake up.
Meet Allan Bogh
I go by Buckwheat469 online but my real name is Allan Bogh. Anyone can find this information with a simple Google search, so it’s no secret. I’ve been a professional web developer since 2001 or so, but I’ve been programming in Javascript since 1995, or around when Angelfire and Geocities were a thing.
My first real programming job was developing websites for a local media company in PHP and Javascript. These were the wild west days when browsers created different interpretations of features, and we were developing on IE 5, so the code was quite complex. AJAX had just shown up and JSON was just becoming a standard.
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.”
Source: Twitter
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.
These flat companies conflated the idea of “Full Stack” to mean “everything and the kitchen sink” when it was originally intended to mean Javascript frontend and backend using Node.js.
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.
We used to develop websites with static files or server-generated code from PHP. The most complex aspect was wrangling CSS styles. Now we have to know Javascript, CSS, CSS-in-JS, JSX, the DOM, Node, Express, GraphQL, REST, databases (all of them!), GoLang, Python, maybe even Java, React, Redux, Typescript, Babel, Webpack, Eslint, and Jest.I’ve worked with backend engineers afraid to get into frontend development because it’s daunting, and I don’t blame them. It’s insane that it’s gotten this complicated. Take me back to the good old days of JQuery and IE5 issues.
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.
Development measurability
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
