cjcenizal

The message I get out of this post is: "Know what you want, and be uncompromising in your search for it." If a company is interviewing you wrong, then the company is disqualified from your list of places you'd like to work. You can draw up a similar list of criteria (e.g. has an open source presence, has a remote-first culture, uses JIRA, doesn't use JIRA, has low technical debt, has high unit test coverage) with which you can assess culture/role fit.

If you find the companies you're interviewing with consistently fail your test, then bring your pattern-identifying skills to bear and figure out why. Maybe all of the companies you're interviewing at have something in common (they're all startups, they're all Fortune 500s, the CEO isn't technical, the roles are too senior/junior). In which case you should break the pattern and apply for work at different types of companies.

Or possibly the pattern lies within yourself. Do you consistently fail the same kind of technical tests? Does your answer to a specific question ("Can you show us a large codebase you've worked on? Oh, you can't?") tend to elicit the same negative answer? Then maybe you should focus on strengthening those weaknesses.

The comment you replied to, and Talia's original post, is representative of the market demanding it.

Here's a technical write-up by Michael Chang, who wrote the WebGL portion of the site: https://developers.google.com/web/showcase/case-study/art-se...

Nice! That's really considerate of you. I'm sure your candidates appreciate the extra time and I bet the Monday conversations are of higher quality, too.

That's a terrific JavaScript exercise, and sounds like a lot of fun. My only concern about the process would be the in-person interview. I recently flew from LA to the East coast for an all-day interview session, and the experience was miserable. My flight was delayed for hours, I got into my hotel at 1AM, I was sleep-deprived, jet-lagged, and exhausted for the entire process, and then I had to rush to catch my flight back as soon as I wrapped up. The flights averaged out at 6 hours in each direction, so I spent 12 hours in the air within a 24-hour period. Not fun, but a great way to ensure your candidate is at his/her weakest during the interviews. :)

This is a great article. I think the term for this code is "zombie code." It's in an undead state - never living, never dying. Just rotting.

Hey, author here. You make a great point. I'll update the examples to be in CSS. Thanks!

I agree. For me, the red flag was when the coworker asked him why he was so stressed. If things are working for other people, but not you, then something on your end probably needs to change. To me, it sounds like the author needs to trust his coworkers more. It's OK not to be involved in every decision. Sit back and let people own some things, and save your focus for the things you've decided to own. Everyone will be happier and more productive.

This is an oldie, but a goodie! Every point in here is golden, and it's nice to revisit this from time to time and be reminded about what's important.

This almost reads like a troll. "Making games is not a job"? If someone's getting paid to produce something, it's a job. No amount of doublespeak can change that. Stop whining about "80 hour weeks"? Everyone has a right to agitate for improved work conditions. This is essential for the capital-labor relationship to benefit society.

The author seems to be contradicting himself -- wage slaves are those who must accept an oppressive workplace to survive. Shutting up and accepting poor conditions, like the author suggests, is how you become one.

These stories are so well-written! Really captures the original style well. They remind me a bit of the koans from The Codeless Code. The simplicity of the story obscures its "lessons", allowing you to apply the story to your own experiences and draw your own insights.

I think you're right but I think you might get some false positives if the person has to pause and consider their answer and you interpret that as a lack of critical thinking skills. I typically fill my mind with current projects and things that interest me and it takes me a minute to shift gears and refocus on a different topic.

From the article, markup that once looked like this:

<div class='questionCard'> <!-- Contents of the card --> </div>

Now looks like this after their refactor:

<div class='u-relative u-mt1 u-p2 v-bg-white v-bs2'> <!-- The contents of the card --> </div>

For a filesize improvement of 19kb to 9kb.

Personally, I feel like the new class names they're using are extremely difficult to read and scan. I imagine the mental parsing time from reading the classes to forming a mental image of the result goes up with the addition of each class and variation. I wonder how difficult it is to discuss design decisions using these terms?

I've found that semantic, component-specific class names make it really easy to reason about markup and discuss UI changes with designers and product people. This increases maintainability and makes it easier to prune classes used by deprecated components, and also decreases iteration time when developing a UI.

I'm based in LA and work with a team in Germany. I think we're most productive when we devote the morning to reviewing code and the afternoon to writing code that can be put into a PR by EOD. This way nobody is blocked. It does require a ton of discipline though because if you don't do the morning review you will fall behind and basically get stuck perpetually reviewing PRs without any time for writing code.

I see your point but personally I think what your brother is doing is awesome. Assimilation is a two way street and I think American culture benefits when it assimilates aspects of other cultures. I imagine your brother is exposing others around him to a culture they wouldn't have experienced otherwise. If people are better off when exposed to new and different people and cultures, then I think he's doing them a service!

This is really great, but like a few other people, I found the music incredibly distracting. At first I thought I had left my Spotify on!

This piece contains same great thoughts. As a Bernie supporter, I want to "win", which to me means achieving a society where democracy is valued, everyone has a voice, and everyone has an equal opportunity to succeed. No matter how provoked I feel by some of the things Trump says or does, I know that any negative action I take or words I say against his supporters will only push them farther away, and me farther from my goal.

The antidote to Trump is empathy.

Here's a great video of Bernie talking about this idea: https://www.facebook.com/actdottv/videos/422038514653387/?th...

I hope these comments give you the reassurance you need to assert yourself. Your partner isn't respecting you or your contribution. Sometimes you just have to walk.

I think the author hits on an important point under the "Common Ground" section: discussions should be collaborative, not argumentative. If you're trying to make a decision with a "me vs. you" mindset, the decision won't get made. Instead, try to frame it as an "us vs. the problem" situation, which helps everyone contribute and work multiple angles to find the best solution, keeping multiple considerations in mind -- including code "quality".

If anyone's interested in more on this, I wrote a short Medium post on other strategies for making better technical decisions: https://medium.com/@cjcenizal/seven-strategies-for-resolving....

I don't think "web developer" has been replaced by "UI/UX engineer". I would still draw the same distinction between the two that you're drawing. But I think demand for "front end developer" has lessened and demand for "UI/UX engineer" has increased.

I think there's a fundamental shift in the type of web-skills which are now in demand, due to a number of factors. Here's some things which come to mind:

- A "web designer" or "web developer" used to be a generalist who wrote HTML, CSS, and some jQuery. Now there's a demand for specialization: a UI/UX designer who can prototype, iterate quickly, and use real data if possible, and a UI/UX engineer who can develop large-scale apps with an eye towards security, performance, reusability, and maintainability.

- The need for the generalist web designer/developer seems supplanted by tools like Squarespace and Bootstrap, which make it easy to get acceptable results with fewer skills. It's the "commoditization of design".

- The need for specialized designers/engineers is spurred by a realization that good design can command a premium/competitive advantage (and that good design means iterating quickly and having a deep understanding of what makes fundamentally good UI and UX), and that the front-end benefits from sound engineering practices as much as the back-end, especially if you're building SPAs or large-scale apps with complex UXes.

- A lot of the design problems have been solved already. Questions such as when modals are appropriate, how to design forms effectively, what makes a good call-to-action, and how to structure IA effectively have been answered. Companies no longer need teams of people to work out answers to these questions, just one or two good leaders to evangelize the answers that are already established, and a team of UI engineers that can execute them well.

Many married couples have joint accounts, into which all/most funds go and from which all/most funds come. For them, there's no "my money vs your money"... it's "our money". The idea is that their marriage joins them into a unit, and the money is spent on the unit. For many people $500-600 is a lot, and such a couple would want the decision to be a joint decision.

To solve this issue I keep component-specific .scss files alongside each component's JS file, in a component-specific folder. A root index.scss file imports all of the components' .scss files.

Coupled with BEM, this also helps prevent component style interdependencies.

I've had the opposite experience. As I've grown as an engineer, so has my appreciation for elegantly written tests. They help me refactor more quickly, anticipate edge and corner cases before the give birth to bugs, and deploy with greater confidence.

The original article which sparked this issue (http://dancerscode.com/blog/why-the-open-code-of-conduct-isn...) states that CoCs will cause people to censor themselves out of fear of offending people.

I think this is fine. You should think about how you will make people feel and how people will interpret what you say. And this is good for you, too. By empathizing with the listener, you can find more diplomatic and effective ways to communicate. You'll reach more people.

And if you can't think of a way to do that (which I think is unlikely in most cases) then maybe your thoughts deserve marination and should be shared later, or perhaps not at all.

Wonderful article. I've recently started growing some sunflowers in my yard. When they're young sprouts and only have a leaf or two, they are very fragile -- if they lose those leaves then their growth is stunted forever. They'll be stubs after that. As some sunflowers outgrow others, the shadows they cast on the smaller ones causes the little ones to twist and bend to escape the shadow and drink in some light.

I think what I love about them is observing their lives play out so much more slowly than ours. They react to their environment and strive for their own goals of survival and reproduction. But so slowly, gently...

Beautiful and heart-breaking.

I can tell that a lot of hard work went into this, which I really appreciate and admire. But I think this approach is fundamentally flawed because it attempts to solve one problem (managing CSS) by replacing it with an entirely novel problem (new syntax and interface for managing styles).

I would rather see tools that attempt to solve hyperspecific probems (e.g. culling unused styles, visualizing namespace collisions) without disturbing existing best practices (e.g. modular CSS, BEM, using preprocessors like SCSS and post-processors like PostCSS).

When I was first learning the ropes as a developer, I found myself in similar situations, and it was equally frustrating (for both myself and my coworkers). What changed was I learned how to separate myself from the code. Programming is a team sport. You're all building a codebase together. And good code should be objectively good so it doesn't matter who writes it. You'll impart maximum value to your team once you learn how to cooperate. That's step 1.

Step 2 is learning how to adopt an engineering mindset. Spend time in analysis and ask your coworkers for feedback on your approach. Critical thought should not change from person to person. If the engineer before you applied critical thought to her/his code, then s/he encountered the same problems and made the same decisions you would, if you also applied critical thought. So spending time reading code and understanding it is a huge time saver.

The critique of re-inventing the wheel isn't "hey you just made a wheel... we already have one of those". It's "hey you spent all your time thinking about wheels and working out all the details... we've already done that thinking and here it is written down. Save yourself some time and catch up to us. We did the heavy lifting for you."

You're doing great! Many of the commenters here are saying this is normal and you shouldn't be worried. They're right. Relax. You're asking questions and learning... don't worry about not learning fast enough. No matter how quickly you learn, it will never be "fast enough"!

Here's some advice which may help. Focus on smaller problems. If you need to solve a problem with an internal tool with poor docs, tell yourself you're not going to solve the problem right now. Right now, you're just going to improve the docs. So dive into the tool and focus on one method at a time. Read the source, the tests (if they exist), and update the docs with the knowledge you gain. Stay focused on each individual aspect of the tool until you're an expert on it before moving on.

This way you'll be in a position of ever-expanding authority, you'll inevitably arrive in a position where you can solve the original problem easily using the internal tool, and you'll have created some docs which will be useful to other people on the team!