Jared Bieberich

I think something like tRPC for a greenfield codebase has a lot of potential or just the built in server components and functions in NextJS and Remix or a monorepo containing your front-end and back-end code. Anything where you can share types across the back-end and front-end would not only be not only a time-saver, but also reduce the possibility of bugs if an API response or expected payload changes. Currently, these APIs are usually documented elsewhere like in Swagger or even better possibly generated from your types like in Fast API which I haven't used yet but looks great. It seems that the documentation step isn't always enforced, and it is tough to track updates that may get posted in Slack rooms and get lost between threads and individual messages. I've always contributed to documenting if I'm ahead of back-end development when not in a full stack role to agree on our API shapes, and after the fact if we catch a change that wasn't documented.

Laravel's Precognition feature looks great too to reduce duplicate validation code for client side forms via “live” validation using the same set of validation rules. In tRPC this again is shared using a validation library like Zod or Yup and a set of rules configured within.

HTMX is another interesting tool in the lane of simplified and very light front-end approaches allowing back-end devs to more easily contribute. I love anything that deviates from the heavier and more complex frameworks that all focused on SPA like functionality and complexity originally, and are now moving back to the server as much as possible. I will always love React and Vue (and the others), but it's good to keep an open mind.

I think 100% code coverage is a big time suck and mainly a way for managers to have insight into code quality or devs to not have to think about if tests are needed or not when reviewing PRS. We should focus on tests when they are helpful, which I know sounds fluffy. A lot of component testing that is either a snapshot or snapshot-esque for stuff like text or buttons that always appear are usually a waste and testing framework or library rendering logic. Include tests for anything conditional and unit test any complex functions supporting your components. Whether you want to do that more visually using something like component tests in Cypress or with a command line test runner - go for it. I find the latter more efficient using Jest/React Testing Library or Vitest more recently. Mock APIs using something like built in mocking or MSW. Or, continue to use the container component pattern where you move the fetching and store state code up, and out of your components. This reduces testing and Storybook setup code, but leaves a testing gap to be addressed if your bug monitoring or QA is telling you it's a problem.

I don't adhere to or advocate for a testing “shape” which seems to change from a pyramid, upside down triangle (tortilla chip), trophy, etc depending on the team. I'm not a fan of dogmatic approaches to most things in software development - be flexible but document decisions and approaches for onboarding, in particular. I generally agree that unit and component tests are the cheapest and should be the bulk of your tests. Beyond that, maintaining a seed database and hitting actual APIs in a test environment are pretty costly. Make sure your bug monitoring is showing you have a gap in testing, and maybe modify your API development processes first before investing in the e2e and integration tests. I'm sure a formal QA team would disagree which is fine - I'm all for doing what's best for the team over time given the size, available testing resources, and types of bugs you are seeing.

Nothing too crazy here. ESLint for coding standards, Prettier for code formatting and standard plugins and rules for each depending on the framework. Pre-commit hooks are great to get consistent use across the team, and can be set up in a variety of ways though I have usually used Husky in the past. Fail the builds in Vercel for warnings for environments beyond feature branches. It's a bit more strict, but great at that level and gives devs a chance to fix any issues in feature branches, reducing failed build notifications for this reason.

We paid for and used Github Copilot with my last company, and it was mostly good. It saved a lot of time with generating basic code, and reducing the amount of visits to StackOverflow or MDN for assistance. It did seem to conflict with VSCode's intellisense functionality at times based on other packages for formatting, types, and autocompletion, but overall I would use it again.

This is a wide subject but let's focus on React as the lens to focus on a more specific example. Generally a new feature may be an entire page/view or a part of one. Start there with a single component, styles, and stories. Document what you already have in terms of shared components that can be pulled in or safely modified to accommodate any new design or feature. From there I will break it up as needed to separate components as it makes sense. Things like list items, charts, cards, and sometimes more complex buttons or interactive elements are good candidates for abstraction. I'm pretty good at knowing what to break up looking at designs and requirements, but don't like to waste too much time up front if it's not obvious (analysis paralysis). Avoiding hasty abstraction and holding off on fully optimizing for reuse can help initially as the ideal solution becomes more clear. As you work with your component/s in Storybook and tests you will also see cleanup and code reuse opportunities to make development manageable now and in the future.

In terms of performance things like useCallback and useMemo are the two most popular React optimization approaches. But they can be overused or misused. useCallback is generally only needed when passing a callback as a prop to a memoized child component or using the callback in an effect. There are a few other usages currently noted in the React docs, but don't blindly wrap every function in a component or hook until you need to.

useMemo should really only be needed for expensive calculations to avoid re-calculating between renders. I've rarely used this except with larger un-paginated lists of data when transforming the original data or with certain packages like Tanstack Table, most recently, also with larger amounts of rendered data. Generally, in the case of transforming larger sets of data from API responses you have options to cache or optimize this outside of components like with selectors with Redux or the success handler of a data fetching library like SWR or Tanstack Query. Similarly with the HOC, memo (different than the hook, useMemo), I have been guilty myself and also have seen some devs that blindly wrap every child component with memo so it is memoized. But again, I prefer to limit adding unnecessary code for premature optimizations. There is a cost, albeit small in some cases, for every line of code, so make sure there is a problem before trying to solve an imaginary or future problem (in most cases).

Usually when I see a noticeable render issue or work with larger lists of rendered data and inspect performance as part of development is when I reach for these rather than pre-optimizing.

I try to accommodate and match their system as much as possible. This means either naming components similarly to theirs or at least communicating that name when referring to it. Same goes for colors or common typography styles - use their names in variables if provided like “mint” or “light-caption”. This makes it easier in discussions or when crossing over to Storybook to be on the same page. Usually designers adhere to a grid system in Figma or their tool of choice so we don't have many magic numbers floating around in our CSS, but it's been a long time since I have worked with pixel pushers especially with responsive design being the norm for so long now. I'm fine during desk checks or async reviews making any level of changes that the team usually makes.

I may bring up possible ideas over time or suggest using a very similar component we already have in the interest of saving time. But if it's important to them and their team is fine with one-offs that's something to consider on a case by case basis. Over time you hear about popular examples from devs like “we have 22 shades of gray!” or “this is our seventh form submit button!”, but ultimately I think other than making them aware of the time and additional components or props to maintain it's not worth getting frustrated if the wider organization is not prioritizing it. Aim to assist, not to get people to bend to your will. Keep the conversation open and candid, but work to move forward given the current processes and patterns adjusting as needed.

More generally than just with PMs I'm most focused on providing business value in whatever role I'm in. As developers we can sometimes get sucked into the summed up pattern of “well, that makes the code messy” or breaks some unwritten rule that we want to stand our ground on. Try not to go down the technical path immediately, and ask questions from the user perspective as planned work is presented. Again, aim to assist by pointing out gaps or unclear reasons for certain requirements, and more widely about what success this feature creates. From there as you get into sizing and technical discussions be flexible with what is possible in terms of ideal solution vs slightly messier but avoiding large refactors, for example. Give options, and make the best decision together to find that balance of managing technical debt while implementing new features.

I have worked on teams where design, dev, and PMs seem to each have some dislike for each other or certain team members based on repeated negative behavior in collaborative planning meetings. It's brutal, and shouldn't be that way. Hopefully, you work on a team where you can be candid with each other and squash situations like this in the meeting or privately with each person if needed. By respecting each others' expertise and function within the business and making sure it's the user at the end of the day that we represent most in our decisions it's usually a fun process to create great software.

Absolutely. I have been fully remote since 2018 on various size teams where some employees are in office, hybrid, or also fully remote. I prefer to communicate mostly through tools designed for async communication like Jira or whatever project management solution a team uses or Confluence for spikes and other documentation. Slack is fine, but quickly becomes overused and overwhelming if folks are not planning properly ahead of standup or sizing meetings and asking questions in one-off fashion throughout the day. Generally, it's easily corrected or not that big of a deal, but getting folks to think and communicate in more detail can reduce the trigger happy communication behavior. I try to use threads in Slack as much as possible to organize the madness of group rooms. Another solution is to use the direct chats to reduce the full room chatter, and post the result of a private discussion for team context if needed.

For larger tickets I will generally commit code several times a day and create reviewable chunks of work daily in feature branches at the end of the day. I can then provide links in the relevant Jira tickets and notes on progress and any possible opportunities for time savings or reuse if something was discovered since sizing. Keeping tickets in the correct lane and up to date is second nature, and any changes in estimates or blockers are communicated via the ticket and Slack potentially to keep moving. I also create tickets for everything that pops up in the form of bugs or discovered work we want to include in an epic. It's important to provide tracking for new unplanned work for co-workers and managers to be aware of if needed.

I usually work normal-ish hours from 8:30am - 4:30pm CT to be consistent, and will update my Slack status if I take a break or need to run an errand. Obviously, there are times where I have to work more for a deadline or high priority bug which I accommodate earlier in the morning or later at night as needed around family time.

My process hasn't changed much in the last ten or so years. I initially started in technical client services roles so time tracking for billable hours was a skill I learned early on. I still track my time even though it's not used or requested by managers simply because it motivates and keeps me honest. I use a terminal app called Timetrap that is basic and just second nature at this time.

In addition to Jira ticket requirements I keep daily logs in Bear using a modified Bullet Journal approach. I have a Planned section where I re-list my calendar appointments for the day to reinforce my schedule and associate notes with each meeting. Then I have the Unplanned and Planned sections where I have detailed breakdowns of both types of work for the day. I try to create todo lists of tasks broken down in the 1-20 minute range. Why so small in some cases like “Create a new branch from the release branch” or “create a new empty component for the submit button”? It's great for keeping you moving or re-starting when you hit a productivity wall. The act of crossing off even a micro task can snowball quickly and get you back on track.

That's really it in terms of making each day productive with two separate tools. More generically I approach each week as an opportunity to win, and find that as the best unit of measure to aim for and reflect on once it's complete. You can have bad hours or days, but overall if your team is agile and open with each other you should be able to correct the course and finish a week feeling mostly positive about the effort we put forth. And then as you get through longer epics or financial quarters you can look back individually as a team and figure out what the record was similar to sports if that is your thing. Within 52 weeks you have 52 opportunities to move the company forward. You will rarely have a 52 - 0 record, but it's an optimistic mechanism to try and do good in measurable chunks each week.

Generally with the smaller startups I have recenlty worked for, I lean towards Kanban or more loose planning processes with some cadence of planning out chunks of tickets at a time rather than on demand. Developers don't want to guess about what tickets they should work on next or have to be pulled into planning meetings excessively. Have them assigned and in order as part of the grooming process. I typically check if I think that the groomed order might not be up to date, but otherwise just move on to the next ticket in my stack. I think standups are great or some type of daily meeting to briefly check in, ask questions, and bring any planned items for discussion. This reduces chatter in other tools like Slack. I'm fine with async review of completed work or desk checks a few times a week at planned times. A regularly scheduled desk check is a great tool for motivating me to get a desired chunk of work done by, and helps in breaking up my personal tasks each day.

For larger teams with formal QA and multi-step sign-offs, I have typically worked in Scrum workflows which are helpful in coordinating more resources. If your team has flow and you get value from the rituals and steps in the way you manage work, keep doing it. I think it's good though to question the value of processes from time to time, and lean towards being flexible rather than dogmatic.

It's company specific, and frankly if the salary, benefits, company, and opportunity are solid I don't care where I slot in. I bring a lot of front-end experience, and can quickly learn and adapt if you are looking for additional new skills. I also have lead experience and founding developer experience, so I'll leave it to you to determine what I am.

I think one thing that is related in determining level and fit not just on the engineering team is to loop in design and PM in the interview process as well to get a feel for those interactions and related collaborative experience. Beyond that, as part of onboarding whether it's a formal setup or more informal for smaller companies is to have some short rotations through PM, design, support, technical customer success, and engineering management. My first job out of college was a management rotational program with a software company where the first 6 months was rotating through sales, client services, marketing, engineering - every department. It was an incredible experience in getting to see the whole company in detail, identify things from an entry level perspective that might be valuable, and form relationships that could otherwise take months or years to happen by chance. I've yet to see this again in my 18 year career, so I'm just throwing it out there as an idea to shake things up and get some exposure across teams at any point in one's career.

Not through the firehose of social media. I prefer to do weekly or monthly batches via JS, CSS, accessibility, and framework specific newsletters. Browser release notes are usually covered in some of these, and if not I will try and check those out as well. Chrome makes it real easy showing up in dev tools after a release. I also will check out conference summaries and videos that seem interesting when posted on Youtube or Vimeo. Here is what I'm currently subscribed to email wise:

• JS Weekly
• Node Weekly
• Laravel Newsletter
• Bytes (from UI.dev)
• React Newsletter (from UI.dev)
• Smashing Newsletter
• CSS Layout News
• A11y Weekly

In terms of books I try to get most of the A Book Apart books as they seem to hit on very important but not always technical topics as well. Some of my recent favorites include:

• Design for Safety
• Design for Cognitive Bias
• Sustainable Web Design

For courses and more long form learning I currently use:

• Frontend Masters
• Laracasts

I haven't been to a live tech conference in a long time, so in that spirit I'll pick some oldies that have stuck in my mind:

• “Build good teams, practice failure, and micro listen (the future of the digital economy)” - Harper Reed (the link is to a different conference around the same time, but I originally saw it at TXJS in Austin). This was a talk that was really cool just based on his experience with Threadless and the Obama campaign team, but the “practice failure” piece in the middle is what stuck with me. Technically, it's a great mindset to think of bugs, performance issues, planning issues, scaling, stress testing, etc before they happen. I also use that almost as a motto even outside of technical situations as well to try and get around high anxiety situations by visualizing the worst case scenario, and realizing it can and probably will be avoided but won't be that bad if it happens in most cases.
• I can't find a link anymore to this talk, but it was a 3 person panel talk also from TXJS with someone from the React team, Angular team, and Ember team in 2015 or around then. This was when “javascript fatigue” seemed to peak as there were multiple frameworks, multiple build and bundler tools, multiple testing options, new IDEs, and hot on the tails of ES2015/ES6 which contained a ton of new features after not much new in the JS language itself for years. It was overwhelming to some, and there was almost animosity between devs of different frameworks on social media and elsewhere. It was refreshing to hear these 3 folks almost collaborate and say what each tool does well and even what some were shifting to basically copy. It was all about respect and working together celebrating the options we have with no pressure to learn everything.
• "Embrace the Backend" - Caleb Porzio This is a cool talk looking back as I think this was the year before he worked on and released the initial version of Livewire which obviously built on these thoughts. I love talks like this that challenge the complexity of front-end frameworks and tooling. It makes some of it seem completely insane and unnecessary. Vue has some of the more straightforward looking components, but the same patterns are dealt with no matter the framework. Don't be afraid of old patterns that are simple, testable, and understandable by a wider range of developers on your team.