Location: Texas, United States
Remote: Yes
Willing to relocate: No
Technologies: Typescript, React, GraphQL, Docker, Python, see Resume for more
Résumé/CV: (PDF) https://joequery.me/static/JosephMcCullough_resume.pdf
Email: joseph@vertstudios.com
Experience: 14 years
Compensation requirements: $165k+ minimum
Hey there! I'm Joe, a Senior Frontend Engineer looking for remote work. Although I have worked full stack and DevOps roles in my 14 year career career, the UI is my true love and React has been a joy to work with over the past 5 years.
I enjoy friendly and collaborative workplaces. I hope to find a place where I can mentor junior/mid level engineers (I love teaching!). I bring with me both my technical expertise and my humanity.
> Meetings are not the desired outcome; deployed, working code is
Maybe if all you want to do is code. I get the sentiment. If you're working on a product, getting input from team members and stopping bad ideas from making their way to the hands of the "don't bother me with meetings, I only want to code" person is important.
You seem to have completely ignored my "Communication is necessary, but not the output". Put another way, meetings are the 'how', not the 'what'. The how is not a deliverable, and so can be changed so long as the 'what' stays the same. You can get input, collaborate, etc, in other ways that are not synchronous.
We've all had that "this meeting could have been an email" experience. Make it an email. Start re-evaluating every meeting; any sort of unidirectional informational meeting can be offloaded onto a doc or recorded presentation just as efficiently. Bidirectional decisional meetings can often be done more effectively by writing up a problem statement, the various options, and a 'due' date for input. Allow people to read over it, comment, propose new suggestions, etc, then at that due date, hold a vote (can be done sync or async). Voila, a decision is reached that allowed for greater amounts of discussion, and was arrived at as democratically or 'loudest voice in the room' (if only a select few people's votes count) as you care to have it, rather than whatever organically happens in your meetings. Etc. In my experience what I'm left with are the meetings where it's the 'personal connection' that matters; these are things like the occasional AMA/Town Hall style meetings, and 1-on-1s. 90% of my pre-COVID meetings turned out not to need to be meetings.
I didn't ignore anything. The product is the output. Code is not the output. Your code is as much the output as communication is. Users don't care if you spent your time coding or in a meeting. They care if the product fulfills their needs. A meeting that stops a terrible redesign contributes as much the output as the heads down programmer who would have implemented it. Now I would hate to be in meetings all day, don't get me wrong. But I disagree that code is the output specifically for a product.
This comment of yours also creates zero progress, so what's your point? In fact it might be even more "harmful" because it implies we should just be okay with anything because in olden times things were worse.
I implemented something similar in ESLint. I also had it search for comments with "[Don't merge]", etc, so that I could quickly jot down in a code comment a change that needed to be made before the PR was complete. The pipeline would fail if this ESLint rule failed. It works well for me but I understand it may not work well for all.
Assuming you're not a jerk and you don't say jerk things, you wouldn't have said this jerk thing being quoted. So saying you wouldn't have said it doesn't change the meaning of what was said.
