I spent a weekend rebuilding Yield.io dashboard. I used Cursor for code generation and Google’s Gemini for in-app yield curve analysis.

Revisiting a Familiar Project

Earlier in my career I worked on financial analytics applications. Since then, I’ve used Yield.io as a sandbox for trying new technology. This felt like a good time to modernize it with Cursor.

Coding with Cursor

As you probably know, Cursor is a fork of VS Code with AI integration. It supports multiple LLMs and has access to your project’s structure, so it can make suggestions and modify code directly in context. For this project, I used it to build a data ingestion and backend layer in ClickHouse, a Vue + ECharts frontend, and integrate basic AI-driven bond performance summaries from Gemini.

The ability to skip over details of learning a new API is, to me, one of the most meaningful wins of AI-assisted development. I’d never used ECharts before, and normally I would’ve had to stop and dig into documentation, and learn the nuances of yet another API. With Cursor, I could just describe the chart I wanted, and it scaffolded a working implementation instantly. Honestly I was surprised by how smoothly this went.

It is fast to generate code with Cursor, but the output didn’t always align with my intentions. I often had to redirect it. It generated duplicated code, built overly long files, or made incorrect assumptions. For example, it repeatedly tried to sort a flat file that I had deliberately structured for easy appending. No matter how I prompted it, it would return to the idea of sorting. I eventually had to side-step the problem by structuring the data into a ClickHouse data store.

It also struggled with some of the more nuanced problems, like browser timezone handling. But, to its credit, that’s a common source of bugs in web applications in general.

In the original version of Yield.io, users could view charts but had to interpret trends on their own. This time, I integrated Gemini to analyze and explain yield curve dynamics directly in the UI. Instead of just data, users now get:

• Natural-language commentary on steepening and flattening
• Comparisons to historical patterns
• Market context based on curve shape

It’s like embedding a fixed income analyst in the product. This moved Yield.io from just being a charting tool to something more interpretive.

Deployment is still manual

While Cursor helped me write code quickly, it didn’t help much with deployment. I still had to manually configure the ClickHouse environment, build Docker containers, and wire up hosting. Cursor could help scaffold scripts or suggest configs, but it wasn’t a DevOps solution. This is becoming a problem with AI generated applications which has already resulted in some high profile breaches.

AI helped in the editor, but production remained a manual process.

Managing Regressions

Cursor encourages fast iteration. Unfortunately, quick changes can break existing logic or overwrite solutions from earlier in the session. I committed changes frequently to git, with frequent pushes. And it does highlight the need for testing early and often, which I did by adding Cypress E2E tests.

Why the Skepticism?

Overall, I’d call the rebuild a success. So why is there so much skepticism around tools like Cursor?

Some of it, I think, is fear of change. Roles are shifting fast, and not everyone feels in control of that shift. It isn’t clear what software roles will look like in the next few years.

There’s also a genuine concern: code generators can be unpredictable and quickly generate a significant amount of tech debt, or code that you have little understanding of if things go wrong. Tools like Cursor require oversight. They help experienced developers move faster, but they don’t remove the need for experience.

Conclusion

Overall I’d consider the experiment a success, especially considering how quickly I was able to rewrite the dashboard, but overall this is a simple project.

While there is significant, and somewhat justified, skepticism among many engineers and developers, I think there is little doubt that tools like Cursor are changing the way software is built.

1. I undervalued vertical market AI applications built on generic LLMs like OpenAI, Anthropic, etc. as wrappers.
2. I also didn't see the value or complexity in "prompt engineering."

Application Data

One of the biggest lessons I’ve learned is that application data is a valuable commodity that significantly enhances AI’s utility. While LLMs themselves are general-purpose, the data they interact with defines their value in specific use cases. Companies that build applications leveraging domain-specific data have a competitive moat: providing context, personalization, and accuracy. This is why AI-driven vertical market applications are starting to proliferate. They streamline AI’s use in practical, industry-specific workflows while benefiting from ongoing improvements in foundation models.

Commoditized APIs

The sudden emergence of DeepSeek, which mimicked OpenAI’s API, highlights another reality: LLM access itself is becoming a commodity. If an API-compatible model can slot into existing applications overnight, then differentiation won’t come from who provides the mode. It will come from how applications use it. This reinforces the importance of application-layer innovation, where proprietary data, workflow integrations, and user experience will define winners.

The Real Challenge of Prompt Engineering

Another area where my initial assumptions were off was in underestimating the importance of sophisticated prompt engineering. Early on, the dominant view was that prompts were simple, and that improvements in models would render prompt complexity unnecessary. That hasn’t been the case.

Fine-tuning prompts, structuring them effectively, and validating their performance through rigorous Evals processes has proven to be a significant amount of work in my current project. Subtle differences can lead to drastically different outcomes, and the best-performing applications are those that systematically test and optimize prompts to maximize reliability and accuracy. This goes beyond simple trial-and-error; it requires a structured approach to benchmarking outputs and refining context.

The Shift in AI Value

The AI industry is evolving in a direction where the real competitive advantage lies not in access to the models themselves but in:

• Proprietary application data that enhances AI performance.
• Workflow-specific integrations that drive real utility.
• Deep expertise in optimizing AI interactions through prompt engineering and Evals.

I initially underestimated how quickly these shifts would occur, but it’s now clear that the next wave of AI differentiation will come from how businesses wield these tools, not just from the tools themselves.

One project I managed was a resource fulfillment and allocation feature. Basically the user could purchase a resource and allocate it with one step. One team was working on the purchase flow and another was working on the physical allocation. The integration happened through a REST API.

While it would be tempting to develop both sides of the API to completion, and spend the end of the project integrating the front and back-end in my experience this risky as mis-interpretations of subtle dynamics of the API can cause the integration to fail or delay the release. It also delays true end-to-end testing development to the end of the project rather than shifting end-to-end testing to beginning of the project.

In the project above we "drove the spike" by ensuring by pressing a button (even though we didn't have the final designs for the button) the user could purchase and allocate storage, while ignoring error paths such as financial transactional and resource allocation failures. Also features such as resource reclaiming were not implemented until later in the project.

This allowed both teams to collaborate earlier in the development process, and baseline end-to-end tests to be established.

Understanding the Spike

The term "driving the spike" in software development refers to tackling the most complex or uncertain aspects of a project upfront. In the context of integrating software projects with multiple teams, it involves focusing on building and validating the shared API early in the development cycle. This spike serves as the backbone that connects various components, systems, and teams, ensuring a solid foundation for further development.

Benefits of Driving the Spike

• Early Validation

By implementing and testing the shared API early, teams can identify integration challenges and potential conflicts at an early stage. This reduces the likelihood of discovering major issues late in the development process, which can be time-consuming and costly to resolve.

• Risk Mitigation

Addressing complex integration issues early minimizes project risks. It allows teams to evaluate potential roadblocks, performance bottlenecks, and architectural mismatches, enabling them to make informed decisions and adjustments before they escalate.

• Cross-Team Collaboration

Driving the spike promotes collaboration between teams from the start. When teams work together on building the shared API, they gain a deeper understanding of each other's requirements, constraints, and coding practices. This shared experience fosters a sense of unity and shared responsibility.

• Clear Expectations

Early integration provides a tangible reference point for all teams to align their work. This shared vision helps prevent misunderstandings and discrepancies in the understanding of how different components should interact.

Steps to Drive the Spike

1. API Design Begin by collaboratively designing the API that will serve as the integration point. Ensure that all teams' requirements are considered and that the API is flexible enough to accommodate changes as the project progresses.
2. Prototyping Develop a prototype of the API along with basic functionality. This will help to validate the integration concept and iron out potential issues early.
3. End-to-End Testing Create a simple end-to-end scenario that involves multiple components from different teams using the API. This allows everyone to witness the integration firsthand and identify any immediate problems.
4. Feedback Loop Encourage open communication among teams to gather feedback on the integration experience. Iterate on the API design and implementation based on the feedback received.
5. Documentation Document the API comprehensively, including usage guidelines, examples, and best practices. This documentation will serve as a valuable resource for all teams during development.
6. Continuous Integration Implement a continuous integration process to ensure that changes made by different teams don't break the API integration. Automated tests can catch regressions early.

Integrating software projects with multiple teams using a shared API through the "driving the spike" approach is a proactive strategy that yields multiple benefits. It encourages early collaboration, minimizes risks, and sets clear expectations for the development process. By focusing on the most critical integration challenges upfront, teams pave the way for a smoother development journey and a successful project outcome.

Urgency doesn't mean rushing, working harder, or compromising on quality; rather, it requires an approach which fosters shared vision, continuous improvement, and customer-centricity. When faced with prospect of deliver value quickly, product teams should constantly ask themselves, "what is the smallest thing we could do which adds value?" Even if a small increment doesn't immediately generate financial results, it instills confidence in users and investors that product development is moving in a positive direction.

Any software which is checked into source control, but doesn't deliver value to customers represents a liability to an organization and should be treated as such. The longer it takes to deliver customer value, expectations rightfully increase. This can be avoid by consistently showing improvement with incremental results.  

Fostering a Shared and Reasonable Vision

A shared and reasonable vision is the cornerstone of a successful product development process. When all team members are aligned with the project's goals and vision, they work cohesively towards a common objective.

Encourage open communication and collaboration to foster a shared vision. Avoid unrealistic expectations and ensure that the project's goals are both aspirational and attainable. A clear and shared vision inspires urgency by motivating the team to work diligently towards a common purpose.

I believe a bit of psychology is at play here. When the team doesn't share a common vision, it splinters and motivation and productivity drops. This can be extremely dangerous to an organization which needs to show results quickly.

Developing Iteratively: Progress through Incremental Change

Iterative development empowers product teams to make incremental progress with each iteration. Instead of aiming for a fully polished product from the start, break the project into manageable cycles, where each iteration builds upon the previous one.

Embracing iterative development encourages adaptability and responsiveness to user feedback and evolving market demands. It allows for continuous improvement, resulting in a more refined and relevant final product.

Release Early and Often: Responding to Customer Needs

Releasing early and frequently is a key practice in agile product development, and was popularized in Eric Raymond's well known paper The Cathedral and the Bazaar in 1999. Delivering a Minimum Viable Product (MVP) to customers, allows you gather valuable feedback and validate assumptions early in the process.

Early releases enable teams to better understand customer preferences and pain points. This customer-centric approach ensures that the final product meets customer needs more effectively.

Effective Meetings: A Catalyst for Collaboration

Effective meetings play a crucial role in aligning teams and making informed decisions. To create urgency, meetings must be well-structured and goal-oriented. Meetings are a large enough topic that they could be covered in an article of their own, but I will touch upon the fundamentals here.

• Set clear agendas and objectives to keep discussions focused and productive.
• Prepare ahead of time to make the most of the meeting. Going into a meeting cold is almost never a good use of all
• Avoid designing the product during meetings; use them to review progress and align on goals.
• Encourage active participation and create an environment where diverse perspectives are valued. Don't allow strong voices or asymmetrical power dynamics
• Remove less important meetings. While meetings are necessary for collaboration, it's equally important to eliminate less important or redundant ones. Unnecessary meetings can consume valuable time and impede progress. Conduct a thorough review of meeting schedules and prioritize the most impactful ones. Removing less essential meetings allows team members to focus on core tasks and optimize productivity.

Decisive Decision-Making: Avoiding Revisits and Delays

Decisive decision-making is crucial to avoid delays and inefficiencies in the development process. Once decisions are made, trust in them and avoid revisiting them unless absolutely necessary. Often the cost of changing a decision is higher than making a slightly less optimal one.

Decisions should be documented, and project managers should prevent the team from using cycles to reconsider a decision which has already been agreed upon.

Focus on Product Value: Striving for Customer Satisfaction

Perfection is an unattainable goal that can hinder progress. Prioritize delivering value to customers by focusing on essential features and functionalities.

A customer-focused approach ensures that the product addresses specific needs and resonates with the target audience. Embrace continuous improvement over the pursuit of unattainable perfection.

Avoid Rewriting Working Software: Minimizing Disruptions

Software rewrites can disrupt the development process and waste valuable resources. This company ending results of such rewrites were well documented by Joel Spolsky's classic Things You Should Never Do, Part I.

When I say rewrite, I don't mean making changes in response to customer feedback or usage. I mean reimplementing existing functionality because of a perceived technical limitation. I've been involved in 3 software rewrites in my career and all of them put significant stress on the engineering teams and ultimately put the product and/or company at jeopardy as release dates continued to slip and slip as parity was never reach with the former implementation.

Most products can be moved to a new design incrementally, and I have successfully worked on projects and UX flows which used different designs systems as we progressed incrementally toward a common paradigm. This can be uncomfortable for UX designers and product perfectionists, but ultimately significantly reduces the risk of failure in the organization.

Heeding Jeff Bezos: Removing One-Way Doors

Jeff Bezos' principle of removing one-way doors underscores the importance of adaptability and agility. Avoiding irreversible decisions allows teams to explore alternative paths and pivot when necessary.

By eliminating one-way doors, teams can foster a culture of continuous learning and innovation. This approach encourages creative solutions and rapid progress.

Conclusion

Creating urgency in the product development process involves embracing an agile, customer-focused, and collaborative mindset. By fostering a shared and reasonable vision, developing iteratively, releasing early and often, conducting effective meetings, removing less important meetings, making decisive decisions, prioritizing product value, avoiding unnecessary rewrites, and removing one-way doors, product development teams can drive transformative results.

The pursuit of urgency empowers teams to innovate rapidly, meet customer needs effectively, and succeed in a rapidly evolving market. Embrace urgency as a guiding principle, and witness how it transforms your product development journey, leading to impactful and customer-centric products which stand out.

As a start-up evolves, it will go through multiple transformations to adapt to market shifts and grow successfully. However, navigating change can be a daunting task, especially for employees who may feel uncertain or resistant to the unknown. Motivating your team during times of change is essential to ensure a smooth transition and foster a culture of resilience and innovation.

Assuming and stating that change is an expected part of the start-up experience isn't a "get out of jail free" card for managers who need to maximize the productivity of their teams during periods of rapid change. It can be easy for managers to forget the human and psychological aspects which ultimately allow teams to perform at their highest potential.

It is easy to underestimate the time and cost of a change to a team's short term productivity and view a team as a "bag of resources" to address problems in the organization, but in my experience teams perform the best when they feel like they are contributing to a shared goal and vision, and understand how their previous accomplishments at the organization contribute to the company's new objectives.

Transparent Communication

Open and honest communication is the bedrock of successful change management. Be transparent about the reasons behind the change, the anticipated impact on the company, and the role of employees in the process. Address their concerns and questions with empathy, showing that their voices are heard and valued.

Involve Employees in Decision-making

During times of change, involve employees in the decision-making process whenever possible. Seek their input, ideas, and feedback, and incorporate their perspectives into the change initiatives. This involvement gives employees a sense of ownership and purpose, increasing their commitment to the change.

Highlight the 'Why' of Change

Clearly articulate the purpose and benefits of the change for both the company and its employees. Help them understand how the change aligns with the start-up's vision and long-term goals. When employees grasp the significance of the change, they are more likely to embrace it.

Provide Support and Training

Change often requires employees to acquire new skills or adapt to different processes. Offer training programs and resources to help them navigate these changes successfully. Assure them that the company is invested in their growth and development.

Recognize and Celebrate Progress

Recognize and celebrate milestones and achievements throughout the change process. Acknowledge the hard work and dedication of your employees as they adapt to the changes. Celebrating progress reinforces positive behavior and boosts morale.

Promote a Growth Mindset

Encourage a growth mindset among employees. Emphasize that change brings opportunities for learning, innovation, and personal development. Frame change as a chance for employees to explore new possibilities and expand their skill sets.

Lead by Example

As a leader, demonstrate your commitment to the change and the values you expect from your employees. Lead by example, showing resilience, adaptability, and a positive attitude during challenging times. Your behavior will influence your team's response to change.

Offer Supportive Feedback

Provide regular feedback and guidance during the change process. Offer constructive feedback that helps employees improve their performance and navigate the changes more effectively. Supportive feedback fosters a culture of continuous improvement.

Create Supportive Peer Networks

Facilitate opportunities for employees to support each other during change. Encourage collaboration and create forums where team members can share experiences, challenges, and solutions. Peer support can help employees feel less isolated during the transition.

Acknowledge and Manage Stress

Understand that change can be stressful for employees. Be empathetic and offer resources or initiatives to help them manage stress and maintain their well-being during the change process.

Motivating employees during change in a start-up is a transformative process that requires vision, empathy, and effective communication. By engaging employees, providing support, and recognizing their efforts, you can foster a sense of purpose and commitment to the company's journey. When employees feel empowered and motivated, they become the driving force behind a start-up's success. As a leader, investing in your team's well-being during times of change will not only benefit the start-up's overall success but also cultivate a culture of resilience and adaptability that will move the company forward in the long run.

I've been wanting to re-write my YieldIO application to Vue from React for awhile. Vue has been my primary framework for about 3 years, and I'm much more familiar with it at this point. Vue feels more modern and less verbose that React, but they both work from similar concepts and I could be productive with either.

The new client is available in my personal GitLab repo. If you are looking example of using Vue for creating an analytical dashboard, I think it is a good place to start.

I wasn't big at marking my time as years rolled on in previous roles, and frankly I lost track of work anniversaries. This year feels a bit different. Today marks my one year anniversary as an Engineering Manager at GitLab.

It has been a great experience and I'm thankful for all the talented people I've had the privilege to work with. Not only have have I had to opportunity to work with a great team, I've become a proponent of the "GitLab way" which includes working 100% remote and global. I'm becoming a steward of the GitLab values.

It is hard to remain relevant in the software industry -- you have to stay ahead of or, better, create the trends. I started my career writing desktop applications in C++ for the Windows API. Could I still make a living with those skills? Maybe. But my options would be severely limited.

Similarly I started working at companies on-site in the US (it is crazy to think how many times I moved for a job). Now I could be planning on going back to an office when the COVID crisis "ends." But at GitLab I feel like I'm ahead of important trend in the globalization of software development -- there is no office to return to. While other companies scrambled to come up with remote work plans, at GitLab it was pretty much business as usual. Throughout my career I've believed that results are what matter, and at all-remote company results are one of the only things there is to measure.

Not everything is perfect, but more often than not GitLab gets the fundamentals right, and I find myself nodding in agreement. I'm looking forward to the opportunities and challenges the next year will bring.

A couple months ago I wrote about my experience working all-remotely. The world has changed since then, and narrative on remote work has gone from: "this might be a good idea" to "we are implementing this NOW!"

I'd like to thank GitLab's CEO, Sid Sijbrandij, for promoting not only All-Remote work, but our Family and Friends first policy with our second Family and Friends day. I'm using some of that time to finish up this post. If you are new to remote work, you might want to look at GitLab's Guide to All-Remote.

I want to revisit one remote working topic, which was probably the most difficult for me to embrace as a first time all-remote manager -- but will become more critical as employees are simultaneously working from home and caring for their children -- working asynchronously.

Synchronous vs asynchronous

Simply, and I'm borrowing from Google's dictionary here, asynchronous means, "not happening at the same time."

Asynchronous is the opposite of synchronous communications which include a face-to-face discussion -- the communication between all parties is happening simultaneously. Other synchronous examples include telephone calls (hi Mom!), video conferences, and, potentially, text messaging.

An example of asynchronous communication would be listening to a pre-recorded podcast. The listener is consuming the information at a different time than when it was recorded. E-mail is another example.

Working asynchronous means preferring asynchronous communication over synchronous. Collaboration means making a request and not getting or expecting an immediate response.

Don't set working hours

If it is your first time managing a remote team, especially if the team is working in the same timezone, it is tempting to set core working hours -- for instance requiring the team to be online from 10AM-4PM. Unless you are working in an environment which requires hands-on monitoring (for instance production or customer services), I would recommend fighting this urge.

I work with people widely distributed, so it isn't feasible for us to work overlapping hours. I also personally work what I call a non-contiguous day. I rarely work full day in a solid block, so my day might not even overlap with people in my own timezone.

When you assume that others will not be working when you are, then asynchronous communication becomes more natural.

Meetings are social

When I first started managing an all-remote team my instinct was to fallback on synchronous video calls -- I will admit to being a reformed Power Point jockey. Someone from outside GitLab asked me, "if all work happens asynchronously, why do you still have video conference meetings?"

I now consider meetings as important for their social aspects -- rather than a venue for collaboration or decision making. You may need to bring awareness to a process change, or outside decision, but I overall I feel like meetings are useful for feeling I "know" someone better because I see their face and hear their voice.

Keep synchronous meetings short, have an agenda, and mostly reference tools and documents where the real decision making is happening.

Latency

Asynchronous work implies latency in communication -- you might not get an answer to an inquiry right away if your counterpart is sleep or otherwise unavailable. Latency in communication takes some adjusting to, but I'd argue that requiring employees to always be available to reply to any request synchronously can add to undue stress.

Unless you are dealing with a critical system failure, in my experience, an immediate response is almost never required. Unfortunately increased latency can mean working on multiple tasks simultaneously so not to become blocked on one thread of communication.

This is the most significant drawback to working asynchronously. It often requires that most employees, including engineers, have multiple projects or moving forward simultaneously. Fortunately modern tools enable quick context switches, but working on multiple projects can increase cognitive load in already demanding roles. I recommend focusing on one task and not context switching when notified by a colleague, but when it is convenient.

Use asynchronous tools

Decisions and conversations around work items should be discussed, documented, and preserved. Document management, wiki, issue tracking, and source control systems allow teammates to collaborate without having to participate at the same time. Prefer these systems over synchronous tools like video conferencing and chat.

Over communicate

I suspect one of the reasons managers are afraid to embrace asynchronous communication is loss of hidden context in office chatter -- they have a sense of what is happening based on what their team and others around them are saying. But I'd argue it isn't effective to depend informal, undocumented, communication.

Since asynchronous companies are missing the informal communication channels and context that the office provides, I encourage my team to over communicate what they are working on, problems they are having, and status. You aren't going to be able to visible see that a team mate is frustrated, but I encourage team members to speak up when they unable to solve a problem on their own. That could happen in the messaging system or

Staying the course

I will admit the number of synchronous meetings I have are piling up. I think most are there, as I mentioned earlier, to provide social context, but I've noticed when the pressure to deliver increases, so does the tendency to go return to synchronous management. I feel like this is a crutch, and something I'm actively improve in my management style. I firmly believe individuals do their best work when they are able to work at their own conveniece rather than the convenience of management.

With the recent uptick in interest in remote work, I thought it would be a good time recap my experience of working at GitLab, an all-remote company, over the past 7 months. It hasn't been without its adjustments, but overall I'm a proponent of this style of work and think it is the future of software development.

Background

I spent the majority of my career as an engineer and manager at a small software company in Lake Tahoe, NV, USA. While Tahoe is a 3 1/2 hour drive from Silicon Valley, it is far from being a tech hub. Our location compounded the common problems of hiring, and we eventually needed to consider remote work.

My first remote management experience was working with a consulting company in the Bay Area, but we eventually moved on to placing developers in Latin America. We specifically chose that location to overlap with our working hours in North America -- which was probably a prudent decision.

While we got some things right (we hand picked developers and treated them as part of the core team), because most of the team, including management, was colocated at the headquarters, I don't think we ever truly succeeded at integrating the teams.

Going all-remote

Fast-forward a few years: I joined a start-up in a fully colocated office in Raleigh, NC, and then last year, my wife and I decided to move back Tahoe, which basically meant working remotely. I was fortunate to accept a position as an Engineering Manager at GitLab, which is the world's largest all-remote company.

There are two aspects which differentiate working at GitLab from my previous remote experiences.

• GitLab is ALL-remote -- not even the CEO has an office.
• GitLab's employees are geographically dispersed worldwide.

While those differences present challenges, I also believe they are fundamental to the success of the model.

Working worldwide

There are trade-offs in every decision, but I believe history will be on the side of all-remote work -- specifically for software development. The benefits of a distributed team (including being able to hire around the globe and work around the clock) outweigh the drawbacks, but there are some differences.

For the first couple months I felt I was managing into the void. The nearest person on my team is an 8 hour time difference away. It wasn't until recently that this started feeling normal.

While I don't track my time, I suspect I work a more or less a 40 hour work week, but I don't work a contiguous 8 hour day. While we strive to work asynchronously, I have some scheduled meetings over Zoom. While it is possible to work a contiguous day (and I suspect most do), considering that all of my team, excluding myself, works within a few hours of GMT, I've decided it is easier for me to adjust my schedule.

In practice it means my early mornings (7-9AM PST) are usually booked to overlap with the end of day in Eastern Europe, and by my own design, I also have meetings once a week at night -- after 10PM PST. I tried taking 6AM PST meetings, but found I couldn't function effectively at that time of day.

Some late mornings and afternoons are set aside for Asia-Pacific meetings, but mostly they are meeting free. Powder day in Tahoe? Hit it! Nap? At times, I'll siesta (as my wife would say) after my morning meetings, or head to the gym in the early afternoon when nobody is there.

Does this work for everyone? Maybe not, but I think all-remote is about being flexible and finding what works for you. If you value your downtime it is rare that someone will expect you to respond right away.

Working asynchronously

The biggest adjustment for me, and an area where I can still improve is working asynchronously.

I came from an environment which valued quick, real-time communication. When you are work in an all-remote, globally distributed environment, that doesn't work so well. During most of my working hours, my team is offline, sleeping, or otherwise unavailable.

This forces communication to be written and documented. At GitLab we make heavy use of our own software. At the core, Git itself provides excellent support for distributed software development, and GitLab adds additional tools for collaboration. While we have other communication mechanisms, the content in GitLab is the single-source of truth. GitLab is only one tool, and obviously not required for all-remote work, but I do think having a location for maintaining the source of truth about work being done is critical.

Timezone ping pong

One of the side effects of working asynchronously is something I call "timezone ping pong." What can happen when you are collaborating on work such as a code review, is you will leave a comment during your working hours, the other person will get back 12 hours later during their working hours, then you make another comment 10 hours later, etc. Coming to a resolution can seem like a slog.

I don't have solution to this, but I have a couple ideas

• Try to anticipate the questions of collaborators
• Don't let one project block you

Asynchronous communication can not be treated like real-time dialogue, and that has some benefits. It forces conversations to be premeditated, and, again, documented. For code reviews for example, this can mean understanding coding guidelines to prevent back-and-forths of agreed upon standards. Thorough and premeditated conversation is an area of constant improvement, but I believe the overall result is a more thoughtful resolution.

Working asynchronously often requires keeping multiple threads of work moving forward simultaneously. For instance as an engineer if you are waiting for feedback from a counterpart team such as Design or Product Management, you should be prepared to move onto another task. This type of context switching becomes more natural over time as your conversation pipelines grow, but it takes some time to adjust to.

Physical environment

Remote work can have the cost saving benefit of not needing to manage physical office space [1], but is also isn't a get-out-jail-free card for employers, as they should be prepared to handle the costs of setting up remote work spaces for their employees.

Fortunately I had a dedicated home office setup before I started working remotely -- a couple tweaks and I was ready to roll. Not everyone has that luxury though and others obtain office space outside of their homes. I don't think I could pull off my non-contiguous schedule without a home office, but that schedule also isn't a requirement for working remotely.

Having worked in open office space environments, working in my home office is a huge benefit for me. Not only can I work from Tahoe, I can have undisturbed time for work and can take breaks in my own house. I'm an audio enthusiast, and setup a stereo system just for my office. It is fantastic!

My office gear includes a 15" MacBook Pro, two 27" 4k monitors, a good USB camera for meetings, a mechanical keyboard, and an office chair of my choice (which I previously owned).

I also wasted no time in investing in a good coffee solution.

Mindset

It is a convention to have the camera on during Zoom meetings. This is a good thing as it forces me out of bed and to actually get dressed. This might seem strange, but it is a formalism which signals that the day has started, or I might be tempted to spend the day in my robe.

Also, a common concern of remote workers is motivation. I will admit I've struggled with this from time-to-time, but I found a few things help.

In an all-remote company, especially as a manager, you are pinged with updates from your collaboration tools around the clock which can feel like an endless deludge. I force myself to clean out my status updates everyday, otherwise they pile up into an unpenetrable mess.

Secondly, and this can help in general, I try to do the smallest thing that will move a task forward. Usually one task leads to another and the problem goes away, but I don't want to trivialize this. There can be a lot of distractions working remotely, especially at home, and it isn't unusual to lose motivation.

Social

I haven't met any of my colleagues face-to-face, and that might be the case for awhile. In the past, my professional and social lives have often intersected. In retrospect, I'm not sure if this is a great idea, and I could improve at fostering a social life away from work.

All-remote doesn't eliminate politics, but it changes them. For one, you don't have to worry about missing out on opportunities or discussions because you didn't meet socially. I believe GitLab is more results focused as a result of being all-remote.

We do have water-cooler type chats and I enjoy the cultural diversity of working with people from around the world, but if you are looking for a socially driven work culture, or thrive on the close comraderie with your colleagues, then working remotely might not be your best option. At this point my life, that isn't something I feel like I'm missing out on, but I could see how someone in a different situation might miss the social aspects of colocated work.

Conclusion

I still have much to learn on when it comes to working all-remotely, specifically regarding asynchronous communication, but it is difficult for me to imagine going back to an open office. The ineffeciency of working colocated becomes more obvious when you start working all-remotely, and with the recent health concerns of working colocated in a traditional office, I think we are at the beginning of a long term trend toward remote work.

[1] In retrospect it blows my mind thinking about how many resources a typical growing startup spends on physical office space. I also remember working as a consultant and causing a stir because I sat in the wrong office.

I'm currently working on an application using Vue and Vuex. Vue is an application framework like React and Angular, and Vuex is a state management library like Redux.

Much of the heavy lifting in Vuex modules happens in Actions. Actions are asynchronous functions and which typically synchronously 'commit' 'mutations' to update the state of Vuex's data store.

When testing Actions, the Vuex documentation recommends mocking Vuex's 'commit' function. Mocking 'commit' can be tedious for complex actions which call multiple mutations. Also it makes refactoring more time consuming, because when mutations are refactored, the Actions which call them must be refactored, along with the both the Actions and mutations tests. This is necessary even if the final result in the store is the same.

A slight alternative is to not mock the commit function, and instead 'dispatch' the action and test the final values on the store itself. This is more of a functional test than a unit test in that it tests the result of the Actions rather than verifying intermediate 'commit' calls.

I implemented a simple example application using Vue-cli which fetchs an array of values using an endpoint from another one of my applications, and displays a count of the values. The values are fetched using an Vuex action:

async getYieldCount({ commit }) {
  const response = await fetch('https://yield.io/api/allYields.json', { mode: 'cors' });
  const json = await response.json();
  commit('setYieldCount', { yieldCount: json.length });
}

And here is the canonical test example:

it('unit tests `getYieldCount` by mocking commit and testing args set on commit', async () => {
  const commit = sinon.spy();
  await yields.actions.getYieldCount({ commit });
  expect(commit.firstCall.args[0]).to.equal('setYieldCount');
  expect(commit.firstCall.args[1]).to.deep.equal({ yieldCount: 5 });
});

This test doesn't update the state of the store. The 'commit' function is mocked and the parameters to the mocked function are tested to ensure the correct values are passed.

The following is an example test which calls dispatch and tests the values on the store:

it('tests `getYieldCount` by calling dispatch and testing results directly on the store', async () => {
  await Store.dispatch('getYieldCount');
  expect(Store.state.yields.yieldCount).to.equal(5);
});

In this case, the 'setYieldCount' mutation is called implicitly by the 'getYieldCount' action.

TL;DR

While the Vuex docs recommend unit testing Actions by mocking the 'commit' function, for complex Actions it can be beneficial to ensure that the final store is in the expected state. To implement a functional test for Actions, call 'dispatch' on the store, and test the final state of the store.

I had a weird dream last night.

I dreamt I met someone socially who worked for a big tech company. Working in software myself, I casually asked the person what he did. He mentioned his department was responsible for the lemon flavor in their product (hey, it was a dream). He then asked if I wanted to try some different lemon flavored sorbets.

I agreed. He questioned which flavor I thought scored better in A/B tests when the tester knew they were being tested. I answered the one with a more subtle lemon flavor. Then he asked which one I thought tested better when the user didn't realize they were being tested. I said the sweeter one.

He said while testers claimed to prefer the subtle lemon flavor, the sweeter lemon flavor performed much better. He typed something into his phone.

He then started describing how they came up with the flavors they would test. At this point some other people had joined the conversation. He asked, "how many different lemon flavors did we develop?" I was being drawn into some sort of combinatorial Fermi estimation problem.

"Hey is this an interview?" He said his company was, indeed, hiring. I called him out and walked away.

Granted this was all a dream -- probably the result of some sort of interview PTSD -- but I couldn't help but think that anything I do online is part of a perpetual interview. I'm sure someone reading this is judging me right now. Maybe I will be in a position to work with that person in the future. Maybe we work together now.

Career development has always had this aspect (we simply called it reputation), but resumes are no longer something you work on when you are preparing for a job. They are now constantly available and groomed on Linkedin.

Companies like Facebook, Google, and Amazon have a significant amount of personal information. As they continue to grow in power as employers, do we know how that profile data will be used during interviews?

I suspect in the future employment will become more algorithmically based. Companies will suck in your personal data in an advanced background check, and spit out a number ranking your potential as an employee. Algorithmic scoring systems are already used to judge the effectiveness of employees, so why not candidates?

Of course, none of this is new, but the thought of being interviewed socially, changed my perspective on the issue. I realized the perpetual interview is already here.

Last week, after a long Halloween day, I scrolled through my Reddit subscriptions and read a familiar headline: You can't impress developers. So don't try. My post from 5 years ago hit the front page of HN and was cross-posted to /r/programming.

I didn't read all the comments or respond, but I understand why many people disagreed. The title was purposefully a bit click-baitish, but I still agree with my core viewpoint: Don't focus on impressing other developers. Focus on your users.

At the time, I was at the tail end of an extended tenure as a manager. I was obsessed with the end product. After a hiatus, I'm a back to working as full-time JavaScript programmer. While JavaScript has its idiosyncrasies and plenty of room for abuse, I find modern JavaScript to be fairly pragmatic. My team, in particular, is results focused. What impresses other developers is quickly adding features which will directly impact our product and users.

We have a hackathon this week, where we will all have the chance to impress each other, and I'm certain we will. The trickest code won't win, but the trickest feature might.