@polotek@social.polotek.net

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

I always have to start with the cynical take. It's just how I am. But I do want to talk about what I think should be happening instead. Companies that want to reduce the cost of their frontend tech becoming obsoleted so often should be looking to get back to fundamentals. Your teams should be working closer to the web platform with a lot less complex abstractions. We need to relearn what the web is capable of and go back to that.

193

57

76

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

I also wanna give a piece of candid advice to engineers who are searching for jobs. If you feel strongly about what framework you want to use, please make that a criteria for your job search. Please stop walking into teams and derailing everything by trying to convince them to switch from framework X to your framework of choice. It's really annoying and tremendously costly.

153

58

32

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

I guess I want to close by stating my biases. I'm a web guy. I've been bullish on the web for 20+ years, and I will continue to be. I think it is an extremely capable and unique platform for delivering software. And it has only gotten better over time while retaining an incredible level of backwards compatibility. The underlying tools we have are dope now. But our current framework layer is working against the grain instead of embracing the platform.

135

11

22

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

And if you're an engineer, you will be able to retain much higher market value over time if you dig into and understand core web technologies. I was here before react, and I'll be here after it dies. You may trade some job marketability today. But it does a lot more for career longevity than trying to learn every new thing that gets popular. And you see how quickly they discarded us when the market turned anyway. Knowing certain tech won't save you from those realities.

125

5

42

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

Replying to

Part of the reason for this is that I believe in "deploy early and often" when building real projects. I don't like waiting until I'm done to figure out deployment. I like to see it live and what that's gonna feel like. It also allows me to show other people the work in progress. It's almost always overkill. But it's helpful for me personally because if I get bogged down with the stuff that's not fun late in the project, I'll probably give up and never get it out there.

20

19

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

Replying to

Anyway, this is where I'm currently at in my "why is it so hard to launch real personal projects" journey. I'm trying to figure out how we can see more "small software". Apps that are useful or fun but will never be a huge business that makes people money. The developer graveyard of abandoned side projects is littered with this kinda stuff.

19

8

3

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

Product teams that are smart are getting off the treadmill. Whatever framework you currently have, start investing in getting to know it deeply. Learn the tools until they are not an impediment to your progress. That's the only option. Replacing it with a shiny new tool is a trap.

108

59

22

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

On a more personal note, this is frustrating to me because I think it's a big part of why we're seeing the web stagnate so much. I still run into lots of devs who are creative and enthusiastic about building cool things. They just can't. They are trying and failing because the tools being recommended to them are just not approachable enough. And at the same time, they're being convinced that learning fundamentals is a waste of time because it's so different from what everybody is talking about.

103

15

38

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

This has been brewing in my head for a long time. The frontend ecosystem is kind of broken right now. And it's frustrating to me for a few different reasons. New developers are having an extremely hard time learning enough skills to be gainfully employed. They are drowning in this complex garbage and feeling really disheartened. As a result, companies are finding it more difficult to do basic hiring. The bar is so high just to get a regular dev job. And everybody loses.

102

35

30

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

If your product is still around in 5 years, you're doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years. That's just how the frontend community has been operating, and I don't expect it to change soon. Even the popular frameworks that are still around are completely different. Because change is the name of the game. So they're gonna rewrite their shit too and just give it a new version number.

101

60

31

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

What's even worse is that I believe a lot of this energy is wasted. People that are learning the current tech ecosystem are absolutely not learning web fundamentals. They are too abstracted away. And when the stack changes again, these folks are going to be at a serious disadvantage when they have to adapt away from what they learned. It's a deep disservice to people's professional careers, and it's going to cause a lot of heartache later.

94

30

23

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

Let's be clear, I'm not suggesting this is strictly better and the answer to all of your problems. I'm suggesting this as an intentional business tradeoff that I think provides more value and is less costly in the long run. I believe if you stick closer to core web technologies, you'll be better able to hire capable engineers in the future without them convincing you they can't do work without rewriting millions of lines of code.

77

56

13

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

I couldn't speak this candidly about this stuff when I held a management role. People can't help but question my motivations and whatever agenda I may be pushing. Either that or I get into a lot of trouble with my internal team because they think I'm talking about them. But this is just what I've seen play out after doing this for 20+ years. And I feel like we need to be able to speak plainly.

71

54

5

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

Replying to

I'm really annoyed at database options right now. Keeping a local database in a container feels bad. It risks losing data. Probably not a big deal for personal projects, but it causes me anxiety. The project is immediately not "low maintenance" anymore. I like managed databases, but getting a separate PaaS to talk to RDS is not a thing. And if the PaaS you're using offers their own managed databases, that's usually the place where you hit the paid tier and the project is no longer free/cheap.

11

16

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

I forgot to mention that I also set up automated database migration systems in my personal projects. I’m such weirdo.
@bo_brinkman@kind.social

kind.social

7

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

Here are some the heuristics I tend to use.

If you're giving hard estimates further than 3 months out, you're probably making it up.
We can and should break large efforts down into phases or milestones. Those should target 3 months or less so the estimates can be meaningful.
Getting good at swaging these 3 months milestones means you can give fuzzy estimates about large efforts. 4-5 milestones means "this could easily take 18 months".

44

9

16

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

I front load the high risk parts. Meaning we work to explore those parts early in the project. The sooner we gain clarity, the sooner we can refine the estimates. You can also do short proof of concept sprints to achieve this goal.
For anything longer than a few weeks, I create documents to outline the important decisions and assumptions I'm making. I loosely refer to these as Project Documents. And in my opinion we don't do enough to teach people how to create these.

44

2

8

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

Replying to

I use s3 for files. This is again something I end up introducing way earlier than most people. For basically the same reason as databases. I just don't wanna worry about losing anything. And if I make it Amazon's problem, that's one less thing for me to worry about. I also tend to see these things as keeping myself sharp on what it takes to make things "production ready". Every single time I do s3 I have to look up the right way to secure a new s3 bucket without just making it public.

6

12

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

I'm fairly confident in my estimates. But what does confidence mean? It does not mean that I hit my estimates all the time. It means that I think my estimates are meaningful and useful for doing planning work. I am also confident in my ability to adjust my estimates as things become more clear. And I'm confident in my ability to communicate these changes clearly to stakeholders so they can decide what they wanna do.

38

5

7

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

I put these thoughts on The Frontend Treadmill on the blog. https://polotek.net/posts/the-frontend-treadmill/

polotek.net

The Frontend Treadmill

A lot of frontend teams are very convinced that rewriting their frontend will lead to the promised land. And I am the bearer of bad tidings. If you are building a product that you hope has longevity, your frontend framework is the least interesting technical decision for you to make. And all of the time you spend arguing about it is wasted energy. I will die on this hill.

27

2

24

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

Estimates will vary greatly based on the size and experience of the team.
Part of the job of a project lead is to break down the work into manageable chunks. This is largely where we design the system to be built. Hint: this part is missing in a lot of dev processes.
Below two weeks or so of work, the ownership should be given directly to the engineer who will do the work. If they say yes, then we're good. As I told someone earlier, I hate "story points" with a fiery passion.

29

2

4

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

Here are some things that I do to make sure I have high confidence in my estimates.

I talk to my team and learn what they are capable of. As a manager or as a peer engineer. Estimates don't mean anything if the other people involved won't or can't do what is asked.
I quickly identify which parts we are not experienced in. What things are outside of our current experience and competence. Those parts are labeled high risk.

26

1

2

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

I didn't realize at the time that the support I had early in my career was not only good but also atypical. It wasn't until my 3rd job that I had my first experience of managers and more senior dev who were unhelpful and also not better than me at what we were doing. That was wild. And pretty frustrating.

24

2

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

For any less than a month, we don't need to do a lot of paperwork. Just create a one-pager and then let's just go do the thing. I should round this out by wrapping it in some context. The statement above implies the kind of environment that I prefer, and thrive in. A fast-paced one where we develop and ship changes in relatively short increments. In recent years, that has meant high growth tech startups. These guidelines won't work as well in other kinds of environments.

16

1

2

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

This was 20 years ago. The industry has shifted in and pretty big ways. As a manager for the last 10 years, I've had different experiences growing teams of engineers. Many of them have the impression that their instincts are the only ones that matter. Many people react poorly to being told "uh, no that's not right." At the same time. Many engineers are starved for experienced mentorship where none is available. There's nobody else to talk to about whether their estimates are any good.

14

18

1

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

I'm glad I asked this question explicitly in this way. Lots of great info in the replies. Thank you all for being thoughtful and candid. I have some thoughts, but they'll have to wait until later. I will share some of my own experience though. I forget to do that sometimes.

14

23

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

But back to estimates. My process for estimates is still pretty informal. Some folks here have pointed to books and blog posts that outline much more rigorous methods. But that doesn't appeal to me. I gravitate towards work environments where keeping things informal is expected. And that usually means there is a lot of flexibility in determining the tradeoffs. E.g. timeframes or scope of work.

9

1

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@agocke@hachyderm.io @slightlyoff@toot.cafe I hear jsdoc typing has gotten really good. In general I think typescript is net positive but only barely. The mismatch with being able to debug the code that actually runs in your browser is a heavy toll. It remains to be seen whether browses will get native typescript interpreters. That would be a heavy lift. And I'm not sure what it would do to backwards compatibility.

8

9

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

When I became a Senior Engineer™, it's because they wanted me to lead projects. But I became the person who had to answer the question "how long do you think this will take?" At this point, I had observed a lot of what more senior people talked about and thought about when they did estimates. I paid attention when they asked me questions about my part of the work. So I started to model those things I had seen.

8

20

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

One of the key things here is that I still had string mentorship and guidance. There were always people around who were more experienced then me. I talked to them directly and explained my thinking. And they would either say "yeah that seems reasonable" or they would say "uh, no that doesn't seem right. Let's talk about it some more."

8

1

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@slightlyoff@toot.cafe yeah all of this tracks. Thanks for expanding. My experience is that very few people at these companies know how to talk about tech in real business terms. So it's not even a problem that can be solved with persuasive influence.

7

12

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

Okay. I can give some if my answers to the question about estimates. I've never been presented with formal methodologies around estimation. In my early career, it always seemed like more senior people would just come to with numbers based on fuzzy intuition and experience. This never really bothered me. It's just the way things were done.

7

22

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

Replying to

@gkrnours@mastodon.gamedev.place the tradeoff for ease of use always seems to be risk of data loss. I think it's a fine tradeoff for some. But it's not something I'm willing to compromise on.

1

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@slightlyoff@toot.cafe I would love to see you expand on this.

4

16

0

Marco Rogers @polotek@social.polotek.net

· 24mo ago

Replying to

@hbuchel@hachyderm.io good luck!

3

1

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

The reason it was mostly okay is that my early career was as a contractor. I worked for firms that hired me out hourly. Estimates were just estimates. If it took longer, we would explain why and renegotiate the hours. There were conflicts sometimes. We missed something huge on our side, the client was in a bind and couldn't afford to move dates, etc. But none of that fell on me directly as a team member.

4

21

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@chrisisgr8@tech.lgbt the magic incantation for a job is react. It's just going to cost you later.

3

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

@jimw@mefi.social yeah this is relevant. We do need to keep in mind that massive shift.

3

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@mez@mastodon.nz yeah I don't know much about the .NET ecosystem. But looking at it from the outside, it does seem to display a similar mismatch with how we usually understand web server capabilities. Thank you for sharing.

2

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@linus@schreibt.jetzt now all you gotta do is wait 5 years and then come back to try to understand that same react project. Your evolution will be complete.

2

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

@ciggysmokebringer@kolektiva.social yeah this is how I interpret it when employees ask for more clarity on their roles and responsibilities. Or to understand how they are being evaluated. They wanna know how to tell if they are doing a good job. The answer is fuzzier thank people want it to be. But it's still possible to give employees more confidence in that answer.

2

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

@ciggysmokebringer@kolektiva.social for help desk roles, I would tell people to get more curious about what metrics are used to evaluate their department. Is it tickets closed per month or per quarter? Is it CSAT score? Is it mean time to resolution (MTTR)? You should understand those metrics, and then ask your manager to help you track it back to your own work. How did your closed tickets contribute to your departments overall numbers. Does that make sense?

2

1

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@meena@cathode.church I'm sorry to hear that. It does feel like infrastructure tech is similarly moving at a breakneck pace.

1

0

Marco Rogers @polotek@social.polotek.net

· 28mo ago

Replying to

@mez@mastodon.nz oh that's super interesting. Can you say more about that backend experience? Which frameworks and what kind of struggles have you experienced when moving away from them?

1

3

0

Marco Rogers @polotek@social.polotek.net

· 29mo ago

Replying to

@spoltier@qoto.org for what it's worth, I hate "story points" with a fiery passion.

1

3

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

Replying to

@raven667@hachyderm.io @evana@hachyderm.io @matt@toot.cafe there is a great ecosystem of solutions for Linux hosting. But they are by no means easy or accessible to most people. It takes a lot of learning. And remember the context here is people who want to make it easier to build and ship small projects. It’s a significant barrier.

0

Marco Rogers @polotek@social.polotek.net

· 10mo ago

@davatron5000@mastodon.social huh. Most of this stuff I don't worry about at all for small projects. A good pass will handle security sandboxing between the app and database. Small app means connection limits and caching are a yagni problem. Etc. If these issues feel like barriers to people (again, specifically talking about small software), then I'd like to address that in some way.

0