i3Systems Engineering blog


Developing for the rest of your ‘users’, seeing the bigger picture while coding

Hi! My name is Samuel, I began working at i3Systems as a software engineer primarily working on the server side of the CLOMO mobile device management services in June 2021.

I started dabbling in programming before University. However, my interests led me through a vibrant and varied career path. I made a few attempts at bootstrapping some business projects and worked in various industries. I eventually came back around to programming and began pursuing a career in it shortly before making the move to Japan.

I left the United States to come to Japan near the end of 2017. I've since spent most of my time here around Tokyo and am living in Machida city now.

While I've settled on software development as a career path for now, I strive to eventually make a successful business of my own.

Before becoming a developer I had a colorful history of experiences, one of those experiences include being lucky enough to study business at the McCombs School of Business at the University of Texas at Austin-- a top business school in the United States. As such, I have some well informed opinions on higher level business management. I’d like to to share some insight when it comes to thinking of programming in regards to the business and stakeholders as a whole.

For those less involved in business studies, a stakeholder is an individual that holds an interest or concern in something. For a business this generally refers to share holders, users, and employees; other parties affected by the business’s operation could also be considered a stakeholder. Modern business best practices dismiss the idea of focusing on only shareholder profit and encourage following a mindset to maximize the value provided to stakeholders as a whole. Without going into too much detail, this mindset promotes longterm business health.

Bringing it back to development, in designing and developing a product, we are tasked with a balancing act. We need to be focusing on making the experience for a variety of users as good as it can be while considering the needs and expenses of the business, with the goal being to balance minimizing the cost and maximize value provided to the end user. However, in order to promote a mindset conducive to a business’s longterm health, there needs to be another party represented in this equation, the employees involved in the company.

What does developing for employees look like?

It can be difficult to capture what it means to consider the various non-shareholding stakeholders' values when talking about product development. Technically simply doing something that leads to an increase in company profit will likely have a dispersed positive impact on the company and in turn employees. However, this is only a small factor in what we can do to develop for our fellow employees. Similarly to designing a product for various target groups of users, it is helpful for us to look at the needs of different categories of non-shareholding stakeholders to see how we can provide value for them.

Future Developers

Make an effort to have easily maintainable and intuitive code. This is perhaps the most important thing we can do to secure value for future developers. It’s no wonder there’s so many established guidelines and best practices available. Work to familiarize yourself with industry best practices surrounding your specialization, but keep in mind that they are guidelines not rules-- sometimes it makes sense to veer from them to prioritize simplicity. And consider refactoring a bit when your code starts to resemble a cheap starch based Italian dinner.

Document and share information about problems you encounter. You don’t have to write a diary about your development process, but making a logically organized or searchable information on solutions to problems related to your project is great. Sharing this sort of information will save hours of stress for anyone who encounters the same issues you did in the future.

Phase out outdated technologies. Moving on from outdated software often times comes with just as many problems as it solves for a project. Sometimes this fact prevents teams from staying up to date. However, it’s important to take into account how much it can mean to a developer to be keeping their skills up to date and not feel like they’re making software that is on the verge of being outdated.

Maintain a useful and unproblematic developer and test environment. One of the most frustrating things a developer can face while making a feature is being unable to recreate data or circumstances to see how a change they made works. Preventing this means planning around how your local servers will interact with APIs and how to make transient aspects of your project like data will be kept in sync across environments.

Write tests and factories. Having tests allows future developers to have confidence that everything is working as intended; providing an environment conducive to focusing on solving problems at hand. Additionally tests provide a safety net that can catch unintended side-effects and prevent failures. Consider using test driven development.

Current Developers

Create opportunities to learn. Whether it’s working on new technologies or having a space where you and your colleagues can share information about new things y’all’ve learned, building knowledge is one of the most valuable things you can do for yourself while developing. Stay mindful of how you can improve while working. Consider taking a minute to look for more information on a topic even if you might know enough to make a solution.

Give time to find elegant solutions to interesting problems. Some of the most satisfying work as a developer can be making an elegant solution to a complex problem. If you’re faced with a quick and dirty solution versus a harder or unknown potential clean solution that you feel motivated to work on, be willing to devote some resources to exploring the clean solution.

Inversely, allow simpler solutions for frustrating problems. When a problem presents itself that is increasing the complexity of your code and you’re at your wit’s end, don’t feel ashamed if you go for an easy solution. While in these circumstances it may be better for others for you to go for a more elegant solution, your work satisfaction matters too.

Make an effort to provide praise and feedback. People love to be praised for things they found impressive. That said, empty praise will lower the impact of your words, so this begins with understanding what colleagues are doing. In doing so you can easily provide constructive criticism as well as praise for impressive work. Be sure to stay positive.

Leave some breathing room when planning. Encountering stressful situations has a profoundly negative impact on happiness. It’s easy to get into a mindset to want to show your worth by tackling lots of work and take off large bites of responsibility. While it’s good to have lofty goals, you should instead take an approach that you’re happy to do more if you get your work done and not bind yourself to unreasonable goals.


Make deployment related functions able to be automated. This usually entails designing your migration or seed scripts in a way that ensures they are only executed if they are necessary. Frameworks like Ruby on Rails provide internal logic for this with built in support for migration status tables. Often times though, this is not the case for seeds that change data or one-off scripts.

Adhere to preferred architectures. Using the latest micro service architecture or some new database can sound great, but adding them in a way that doesn’t fit into the current operations can significantly increase the operations maintenance workload. Sometimes this takes learning a little bit about the operations of your project. Make an effort to understand the deployment process and work with your operations to design the project’s architecture.

Testers and Support

Design intuitive user interfaces. By making an interface that is easier to understand and use properly, you can eliminate unnecessary inquiries and reduce overhead knowledge needed for testing. Aim to reduce the work needed to understand how to properly use your product and consider how users of varying abilities or disabilities will use your software. Establish clear usage guidelines and limitations. Usually a good user interface is enough and is preferred - and it should be documented where any user can access to it - but having statements on how a feature or product is supposed to work can mean a world of difference in exploring why feature isn’t working as expected. Provide testers and support debugging tools and environments. Even if a tester or support person isn’t an engineer, they will likely need to look up information. Provide special administrative feature tools, or even just show them the ropes for a few tools the developers use.

Marketing and Sales

Design well-packaged marketable features. Often times marketing/sales teams will be guiding the direction of projects to begin with, but in the case you are able to have a developer driven project you’ll want to keep in mind how you can make it catch interest and be desirable. When determining overall design of a project, consider how the features fit together to create a cohesive service package. Focus on making a solution to a problem.

Make key aspects of the project publicly visible. One of the easiest ways to build trust in a product is to have people interact with it. When possible, consider adding features to a demo or free version of your product.

The developer community

Ask and answer questions on online forums like Stack Overflow. Generally the first thing you should do when approaching a problem is to see if/how other people have solved it already. Sometimes information is not available and we have to dig around through source code or create a unique solution. In these cases it’s great to ask the community early on in your search. If you find answers for a complicated problem you should try to come back around and provide an answer for others-- even if it’s been a few months or years since a question was asked.

Contribute to or develop open source projects. Making portions of your project use open source not only helps the community, but simplifies the code base by abstracting the logic to an isolated piece of logic that can be maintained separately and version controlled easily. Web components are a prime candidate for this. Resources like WebComponents.dev provide an excellent framework for making a publishable web component with ease which you can then include in your projects like you would any other published library or web component.

What does this mean for developers?

Many coding best practices are abstractions of the things discussed here. Following good coding, design, and work practices will generally come back to make the life of you and those around you better.

Consider that you and your coworkers are some of the biggest stakeholders in your work. Not everything you do has to directly correlate to a direct increase in profit to be beneficial for the company. Feel free to lend your voice to support projects that will make work more enjoyable or help the community.

In summary, internalize the interests of your fellow co-workers and community and understand the impacts of doing good for them and let it be a guide for your design decisions and motivate you towards success.

In the scope of software development management

Keep workflows simple. Developers are often good at making things, but a good developer can be held up by a complicated workflow. Work to eliminate or simplify the paper work that gets in the way of coding. This is especially important with companies transitioning from a waterfall workflow to Agile / Scrum as in order to have a high functioning team you will need minimal friction to changing directions during feature development. Having detailed design documents that need to be approved any time there is a change is not good for this.

Don’t scold people when they are trying hard. From time to time developers may make mistakes that end up causing setbacks in plans. Do not scold someone for this; it will cause stress and build resentment. Most developers are intrinsically motivated-- they want to make the best product possible just as much as the project owner. That said, sometimes it’s necessary to identify why a problem arose and establish either behavioral or structural changes to resolve it. In these cases, focus on ways to resolve the problem.

Ultimately, management needs to balance profit focused business goals with the values of stakeholders. Understand that employees are one of the biggest stakeholders a company has. Be willing to expend time and resources to promote product development and design that will positively affect those inside the company. Taking employees values into consideration is going to bring out the best in them while spurring an appreciation for the company; ultimately securing the business’s future.

At i3Systems

I feel that i3Systems gives developers a lot of freedom and empowers us to make suggestions and influence the direction of development within the scope of our projects. This means we are able to express our values and make products that are representative of our ideals. Similarly I feel the developers are motivated and want to make the right decisions. I'm hoping that this article will help provide fellow developers with a decision-making basis for determining what is best in the bigger picture.

For those interested in working at i3Systems, please check out the hiring pages below!

2023 New Graduates


General applications www.i3-systems.com