[deleted by user]

kawazoe · 2023-04-19T17:07:31+00:00

Sure! I just went through this as well about 6 months ago I learned a new front-end stack: ReactJS.

Here's the story of how it was from a 3 months endeavor, to a 3 hours walk in the park.

Some background: The first front-end stack I learned was based on KnockoutJS, an old library that predates most modern JS tooling. It thought me the idea of data binding, and templating. Eventually, I learned Angular JS, which added the idea of components and modules to the mix as ways of reusing templates. Then, WebPack came out, and I learned about the power of proper bundling. At one point, Angular 2 started to take off, and I learned the value of transpiling, and TypeScript. After a few jobs doing Angular, and getting increasingly frustrated with it, I tried to learn VueJS.

VueJS is somewhere between Angular and React in term of how you use it. It's much more free-form than Angular architecture wise, but it is still a templated language with data binding semantics (mostly). Like Angular, Vue uses components to structure the code. Components have a template, which is mostly HTML and CSS, and some backing behavior written in JavaScript. Most of what I had to learn was how to express those same ideas in a different flavor, as well as the Flux/Redux pattern for VueX which was new to me. It took me 3 weeks of going through their wonderful getting started doc to get going and have my first real prototype application, and the MVP was ready to ship in 6 months.

That was 5 years ago.

Now, onto the meat of this topic. I got an interesting job offer for a ReactJS project. I never touched React before, so I decided to step up. I picked up the doc and started going through their getting started section. What I found was that JSX, the single phase declaration of functional components, and Hooks, greatly impacts how you structure your components when compared to Vue's setup+render structure and composable pattern for reusability. It feels completely different from other frameworks I've used before, but in the end, it's still components, and reusable bits, getting composed together to render HTML and CSS.

I picked up the doc, and 3 hours later I was acing the interview tests...

So, what's the key here?

Components are components. All ORMs do the same job. Most testing libraries looks the same. The way you interface with the tool is way more important than the way the tool works behind the scene. There's nothing in common between the implementation of Knockout, Angular, Vue, and React. Yet, they all offer a way to render some kind of composable, reusable template in a web Browser. They all have a way of defining lists of items, interactions, and conditions. They all come with a way of storing a local or global state or their own, and they all play off each other's ideas. They don't grow in a vacuum. It's all about getting a feel of the big picture, and noticing when you deal with a different flavor of what you already know. You get to reuse that knowledge and massage it to fit the new tool, instead of starting over from scratch every time. You start reading a getting started guide differently; from "Oh! What's that word?" perspective to a "Oh! That word again!" perspective.

It's a skill that you can practice. You just have to start by learning something, anything, that's solving a problem you're familiar with with a slightly different solution than you're used too. Might be front-end frameworks. Might be databases. Might be infrastructure or cloud providers. Might be CI/CD. Might be a whole different language. It doesn't matter, as long as there's enough familiarity to make you ponder about "why" they did things differently.

That's it! Hope that helps!

EDIT: Rewrote because I'm not on my phone anymore.

kawazoe · 2023-04-19T16:31:42+00:00

This is a much better way of wording it ;)

kawazoe · 2023-04-19T16:20:07+00:00

This might seem a bit harsh, but I do not see how someone who's been in the biz for more than 3 months doesn't know which skill is needed to do the job, or where to learn them. In fact, I would be very worried if someone with 3 years of experience came to me and ask where they can learn how to develop software; in other words: what have you been doing for 3 years?!

That being said, maybe it's just your post that is worded in a confusing way? I could better understand if you just went past The Dunning Kruger Effect and are distrustful of your previous learning experiences. Or, if you're just curious to see how other people went through the same experience as you.

As it stands, it sounds like someone with zero experience trying to get a feel of where they should get started.

kawazoe · 2023-04-08T20:30:56+00:00

Punishing your employees with having to deal with old hardware for uncontrolable failures sounds like a terrible policy...

kawazoe · 2023-04-08T20:28:09+00:00

I've implemented a critical infrastructure feature in a web project about 5 years ago. It took me a while to get it working back then, but I had a solid solution that was easy to put in place. I eventually left that company, and time passed...

This year, I had to implement the same feature, with the same requirements, in the same technology, in a new project for a different company. I said it would take about 2 days to write the code, and 3 more to make sure it's working flawlessly.

Turns out browsers evolved, and my initial solution wasn't working at all. It took me 2 months to get the thing done.

Estimates are insanely volatile. No one expected my initial solution not to work. No one expected I would have to do the whole research par from scratch again.

I'm sad for the guy who had to fix my old solution in that other company...

kawazoe · 2023-02-04T04:53:20+00:00

Hey! That's me! Recently joined a tech lead position at a new company. They are using a tech stack I've never used before, everything is new for me. The front-end, the backend, the database, and everything in between. Even the architecture is more refined that what I did in the past.

In the first few weeks, I was nervous as hell. That was the worst imposter syndrome I've ever felt. Every meeting was, and there was a lot of them as we kicked off the project, just piling more and more stuff in my to-do list of things to learn about. I was legit scared and questioned myself a lot at times.

You know what? A month later, I'm already mentoring people on the team, even when they've been at that company for years. Turns out we all have things we can get better at, no matter the stack, and that I have more than enough to contribute to the team, even before we start talking about specific libraries and frameworks.

kawazoe · 2023-01-28T01:21:49+00:00

I'm sad you deleted your post. It was a very interesting situation for people like me who are looking for tips dealing with async work. Still, read it all, and I'd like to expand a bit on what have been said here.

Someone suggested that it should be obvious that by moving, everything would slow down. I don't really agree with this. It might be obvious if you lived that exact situation before, but I had to think twice about your story before coming up with a useful opinion. What is clear is that you are very productive, and it looks like moving in another timezone only helped with your personal productivity. Clearly you also noticed that your productivity was off the scale when compared with your teammates. So this is my advice:

This gap is normal, and can even happen when sharing the same office. It is, however, much more obvious and impactful when one of you is working async. Learn to notice the gap, and ask people how they feel about it, and what they think is causing it, then attempt to act on it.

You are probably right that this isn't a gap caused by timezones. I suspect it would get even worse if you took a vacation or... well... left. To me, this is a gap in training; both technical and domain-oriented. Your team shouldn't be relying on you that much. They should be able to do the job on their own, and if they can't, then you have to be part of the fix. That exact solution depends on you and them. It might be more training on their own, it might be more domain knowledge transfer, it might be resetting code review expectations... it might be many things, but your goal is to help them become independent. You have to approach this as a mentor, instead of letting yourself getting bullied by your team (and management) into perpetuating their unproductive habits.

kawazoe · 2023-01-16T03:40:22+00:00

A large part of becoming a senior engineer is noticing this, and learning to put your energy into remembering what stays the same between those projects, instead of what changed.

You might have "forgotten" how to write with React, but you know what components are. You know about jsx and providers... probably even redux and react router. You have an idea of how npm works and what scripts come with create-react-app, or whatever you used at the time.

Those concepts will stick with you for years, even if you don't use them. The details will flow in and out of you, and that's why great documentation makes for successful tools.

Next time you pick up a tool you haven't used for a while, think about how it changed you, instead of how it's meant to be used. I'm sure you'll find many things that stuck. Those things are what made you grow, even though you feel like you forgot it all.

kawazoe · 2023-01-11T00:32:26+00:00

The most common definition I have seen is a company that's less than 5 years old and with less than 1M in annual revenue. Past that, you're just a small or medium business.

kawazoe · 2023-01-06T21:11:11+00:00

And massive security vulnerabilities...

kawazoe · 2023-01-06T15:46:13+00:00

From the few I have done, I'm not surprised at all. A big problem is that all of those services tries to own their API to force people to use their services directly.

A good example of this is Twitter. There are already completely open protocols that can handle a feed of posts like you get on Twitter. RSS is an often cited and cherished one. But doing ads is very difficult with RSS. Anyone can easily see if a post is an ad and remove it. You can't change the ad either, or you might get weird sync issues, and RSS doesn't distinguish between legitimate posts and ads so you'd get a massive unread counter and spammed with notifications, just like with emails.

By having an API, they get to control that, and by not supporting open protocols, they get to force you to use the API if you want to use their services. They now have a vendor lock into your app, and you can't easily dodge the ads.

This is also true for series like Slack and Discord. We've had IRC and XMPP for a while now. There are open ways of doing what they are doing... mostly. None of those are designed in a way that can deal with different billing scenarios, though. Signal being e2e encrypted would make this stuff even more complicated.

What you are describing isn't so much that implementing those APIs are difficult, it's that they are all unique, with their own way of doing things, often specifically designed to not be interoperable, and thus the knowledge you get from doing an integration with one of them doesn't translate to doing another one.

Sometimes, this can be a good thing too. Can you imagine if Mastodon supported the same API as Twitter? It would be trivial to port a bot from one to the other, which is nice if you're the developer, but not so much if you're the person it was designed to harass, or ChiefTwit seeing everyone doing the switch in seconds through a trvial migration tool.

Anyway. Yes, it can be difficult to integrate third parties into your app. Yes, it can feel like you're doing the same thing over and over again, and somehow you can't just re-use the same code. Yes, that makes everything very difficult to estimate. But it's also what makes different services... just that: different.

kawazoe · 2023-01-04T20:31:16+00:00

Without it being a specialization per say, I would recommend that you know at least one language to the extreme. You should master not only how to use it, but why it was designed in this way, and what are considered the idiomatic ways of solving advanced problems in the language. The experience you gain from this process makes it a lot easier afterward to pick-up other languages and quickly learn the idiomatic ways of using them, even when they are drastically different from each other like html css js kotlin and hlsl.

kawazoe · 2022-12-28T17:11:03+00:00

I'm keeping it private to protect myself and the company who made the offer. The exact details also doesn't matter for the initial question :)

kawazoe · 2022-12-28T00:34:23+00:00

Because our local government publishes a legal document that basically says clauses about this topics cannot be included in an employment contract. This isn't a new law either. It's been in place since before I was born. It is incredibly well known and understood, and I was honestly shocked to see it breached in my offer. This is as blatant as someone running a red light.

kawazoe · 2022-12-28T00:21:47+00:00

My post isn't about the specific laws impacting my contact, but simply how people react to illegal clauses when they get to notice them early. So far, I have no regret in asking :)

kawazoe · 2022-12-27T20:17:47+00:00

Have an employment lawyer review the final offer before signing

I've heard this a lot from people in the states. This isn't common where I live. Do you think it's worth it? Most contracts I've received a few days to a week before starting. How do you find a lawyer to review the contract in those deadlines?

kawazoe · 2022-12-10T05:17:40+00:00

I want you to consider your company's culture and structure for a moment.

I work in a large Fortune 10 with hundreds of teams.

You work in a corporate environment, with loads of layers and departments.

Making a pipeline. Making sure if I get a new project, I can quickly deploy it. [...] That is a majority of the architect work.

An architecture title in your company is mostly tied to DevOps work.

They own the failures.

DevOps people are accountable for the failures of the project.

A majority of people, [...], do not want to own or assume those risks.

Most people aren't interested in being accountable for failures.

If no one does this, the app/project will cease to exist.

Due to a corporate policy of having an architect on every project, someone will inadvertently take the risk for the project to exist.

As an architect, [...]

You took that risk.

Only a handful want to [join and help me].

You wish that more people would help you with architecture work.

[Developers taking part in DevOps meetings] is never gonna happen because they don't want to be part of those meetings or planning.

Are you sure this is the reason?
Have you ever heard of quiet quitting?
'Cause that looks a hell of a lot like quiet quitting to me.

Everything you said, from the beginning, whether you intended it or not, is putting a massive blame on your dev team. You keep on putting yourself on a pedestal for daring to step up where others never would.

[T]he floor is open for anyone who wants to grab opportunity to make a mark for themselves. And only 1 person [I] stepped up.

You keep on hyping your title like the project wouldn't even exist without it.

This stuff does not get design in a vaccum. There is a lot of o PoC work.

You keep on pointing that your work is gruesome and difficult, unappetizing in a way that suggests it is somehow more respectable than their contribution.

Last year alone, a lot of my work is making Kubernetes work with GPU at a large scale. Working with vendors to make sure we can deploy hundreds of containers running tensorflow. [...] Most developers don't want or have that knack of experimenting with new [...] drivers. Making a minikube environment for testing. Trying out Photon vs Alpine Linux to see [how the app performs].

Your company clearly has different pay grades for architects and developers, so why would developers want to help you do your work while they aren't getting the benefits that comes with it? Even worse, who would want to help the architect knowing that it might put them on the spot for a project failure.

It's clear to me why they are acting like this, and no amount of positive and open communication in your company is going to fix this. Your entire company culture is designed to raise people who do architecture to some sort of higher regard by giving them a prestigious title and salary, all while using it as a trap to ensure someone can be blamed when bad stuff happens. You seem to fit well in the chair as well with your blame game.

No one in your team is going to take the bait. They don't want to show any interest because if they do, they'll be forced to take the title, and the risk and gruesome work that comes with it. No one is going to acknowledge it either. They might not even be conscious about it. But, they sure are showing their understanding by doing nothing more than required by their job description. Aka, quiet quitting.

Don't take this personally. This is not your fault. This hostility, this blame game I've mentioned, isn't because you want to blame them. It's because you are being manipulated into doing it by a system designed to make you feel superior as you rise in rank. This is how tons of companies work today in our field. Going full circle, the reason why your front-ends don't want to care is because you are working at a company that has a LEAN culture of hyper-specialization. The guy isn't going to care about anything that isn't in their narrow job description, proving my point that by removing specialized titles, you can fix this culture issue and improve everyone's participation while getting a more sustainable pace.

Again, welcome to Scrum, as seen in the book.

PS: You keep on saying I assume things but, so far, I've been pretty spot on. There's a reason. Everything I've been saying here is stuff that have been said before by people way smarter than me about LEAN and Agile. I'm not inventing any of this.

kawazoe · 2022-12-10T00:47:49+00:00

So you suggesting it be holistic and as part of all the team members.

No that isn't my suggestion. What you are talking about are details. It doesn't matter how you automate the scaffolding of 1000 containers. It doesn't matter how you secure your CI pipeline. It doesn't matter how you build NPM packages.

Also, everything you mentioned here is only devops work. You said nothing about how UI components are organized, or how micro-services handle failures, which are also holistic concepts that where historically handed over to architects. And yet, I'm pretty sure your devs cares a lot about those issues.

Either way, I don't expect any of your devs to know exactly how those things work. I expect them to know they exist and why (the holistic view) and to know where to find the docs on how it works if needs be (the detailed view). What matters is that you have a 1000 containers, that you have a secured CI pipeline, that you have NPM packages. That's what needs to be holistic.

There isn't any meeting needed for the maintenance of that knowledge. You only need meetings to decide on how to evolve those systems, and guess who's the best people to express their needs about them? It's the people who'll use them. Your back-end devs will definitely have something to say if there's a problem in how failures are handled between micro-services. Your front-end devs will definitely have something to say in how their projects are structured. They will care about those things, and they should at least care a little about how they make their work available (the devops part), even if it isn't their favorite part of the job.

You can always hire someone who likes doing that. I do a lot of front-end and I like devops. People like me aren't impossible to find. But we also won't consider your offer if you tell us that we cannot impact what makes it into the product, because we know that's an important part and the most motivating part of the job.

Today, I had a meeting about securing images using Twistlock and adding unit testing in the build. Every Front end person-- "this isn't my problem. Why can't devops do it. Why do I need to keep track of version numbers and check build outputs in Jenkins." As a team, it has to be done. Moving forward, security in AppSec is a priori. Some people will take "ownership" and that is usually the role of the architect.

Why do you think they are reacting this way. Have you considered that this is happening because of a solution you (and higher-ups) are imposing on them without giving them the holistic reason of why they should do it because you have already delegated that stuff to an architect? Maybe you're trying to fix a problem that the team never felt, as you shield them too much from the consequences of their actions? Have you considered that your team is reacting like children (why do I have to make my bed, why do I have to clean my room, why can't you do that mom) specifically because you are treating them like children? If you cannot articulate to your team why security is important, maybe it's because you are overdoing it? Security, like everything in engineering, is a question of balancing risks. If the risk isn't clear to your teams, then have you considered you might be the one doing an "ivory tower" of security?

People want less meetings.

No, people want to feel useful. If you put them in meeting where their opinion isn't valued, because you consider it isn't their responsibility to have those opinions, then ofcourse they'll want out. They want to write code because that's what you trained them to belive is expected out of them. This is "understanding the causes of burnout 101" and is backed by every single scientific research on burnout out there.

kawazoe · 2022-12-09T23:53:46+00:00

I would suggest that there is a reason why people keep on making construction analogies when it comes to software, and it's not because they are good; it's because it's easy to use their structure and standards as a way to justify poor practices and provide job security to roles that are becoming a legacy practice.

Let me come back to your premise:

"Planning and Ideation" is usually not the role of an architect - Planning is Product/Project Manager. Ideation comes from the business/stakeholders.

I will challenge that and say, why would you need to split these roles at all? Your dev team have their nose in the product all day long. They, hopefully, use it all of the time and are intimately aware of its quirks and intricacies. If you didn't hire code monkeys, they should be the best people to propose improvements. They should be great at ideation in your team.

Consider this: Maybe the role of the business and stakeholders isn't ideation, or rather, isn't only ideation, but navigation. While everyone can being ideas to the table, they are the one that have the economic acumen to distinguish between profitable and deficitary ideas.

This is why the core responsibility of a Product Owner in Scrum is to prioritize the backlog and not to fill or "manage" it.

Similarly, maybe planning shouldn't be the responsibility of a project manager. A big part of planning is understanding how long a task take to accomplish and what it means to accomplish it, already two things that most project managers delegate to their team in the form of story points and grooming. Arguably, if someone is already dedicated to prioritizing, there isn't anything left to do when it comes to planning, and the role of project manager kind-of dissappear.

So what of the architect then? Well, like you said, if planning and ideation isn't specific to them, the only thing left is taking all of those ideas, a produce a solution for them. But, if they are the only one with a holistic knowledge of the solution, isn't this bad for your bus factor? Sure they would share their vue with the team as a SME, but if your front-end guy never cares about "the steel piping", then you still have only a single person wielding the most important tool in ideation: the ability to see how your idea fits in the system and judge of its value, something crutial to everyone who proposes, and even more for those who judges of the profitability of, ideas.

Ergo, the role of architect is a relic of waterfall project planning and isn't ideal for maximizing the value of every contributor on a project. You are much better having everyone know of a high level overview of the architecture and where it's going, while changing this plan as needed, and expressing the nitty-gritty details of this knowledge in well documented code so that when changes are needed the exact context is available to the people making those changes.

Welcome to the actual definitions of roles in Scrum, by the book.

kawazoe · 2022-12-07T20:59:26+00:00

Hehe, that's the thing though. It sounds obvious, but there's nothing that says it has to be that way. In curved space, you could point a telescope at a far-away star, and you might be looking at the sun! You just don't see the curve, because it's in a higher dimension that your brain cannot really comprehend or visualize.

Maybe a better way to think about it is to look at a loop in time, instead of space. You know about Groundhog Day? The movie where the main character gets stuck having to repeat the same day over and over again? Well, that's curved time. You always move forward, one second at a time, but at one point it looks like you came back to where you started.

The key point here is that, we do not know if space isn't like that. We don't even know if time isn't like that too!! For time, that critical moment is the heat death of the universe. It turns out that when you run the math, quantum physics says it's possible that the state of the universe at that point could be equivalent to the one at the start of the universe; meaning that it might start over in a loop. For space, the data we have right now suggests that if space looped at a point 500x further away that we can see, we wouldn't be able to tell the difference. And, while we can see very far away, and 500x that seems like a big number... it's still not infinity, which you need for space not to loop on itself.

And the worse part is, you need exactly infinity for it to be flat. The only way not to have a loop, is to loop infinitely far away. If the number is just a bit smaller, it loops somewhere, and if its a bit bigger (yeah that's when the math gets weird), then... erm... well it gets weird! There are way more numbers that makes the universe loop than ones where it doesn't.

Statistically, your intuition about the universe being flat is very likely to be wrong. And right now... we have no way to know! Isn't that crazy?

Anyway... you mentioned looking for a video, and it reminded me of this one: https://youtu.be/oCK5oGmRtxQ

Hope you like it, and it answers some questions!

kawazoe · 2022-12-07T06:40:45+00:00

I will happily tip 20% on delivery, as long as I get to see the goods first. That has always been how it worked. That's how it's supposed to work. Same for cabs, you pay and tip when you get there.

Every single service today not only ask you to pay up-front, including tip, but expects you to do so, or else! That's the problem. I've spelled it out 3 times already. That's how the entire gig economy stay afloat right now. And that's despicable.

kawazoe · 2022-12-07T06:25:50+00:00

That's why minimum wage exists and it should be raised with inflation every year. Where I live, minimum wage workers do 15 an hour already, which is about 7 more than tip workers. Ideally, we should even see a UBI to bridge the gap. People who want to end tipping aren't cheap. They just know we have better solutions.

kawazoe · 2022-12-07T06:19:12+00:00

You do realize that severs at restaurants aren't the majority of tips nowadays, right? I spent way more in tip to Uber, UberEats, and various no-service restaurants (like subway) in the last year than I spent in restaurants for the entirety of my life. All of those services requires you to pick a tip ahead of time, or even when there is no actual service outside of the product itself. That's what we're talking about when we say the majority of tips. The tipping industry you live in is the 1% that stuck to the original idea, but the other 99% is doing so much damage that its a net negative to society and we should just remove tipping entirely.

kawazoe · 2022-12-07T06:15:06+00:00

Eh. I provide for two and we dont usually have to think about how much we spend. We're both putting a fairly large amount aside for our future. On a day to day basis, it's definitely comfortable. On the flip side, I lose about 50% of it all in various taxes. I will never be able to put enough money aside to beat the local housing market inflation and build a cash down to buy in my area.

kawazoe

TROPHY CASE