Comment by NAHWheatCracker | Hacker News Reader

Comment by NAHWheatCracker | Hacker News Reader

Parent Full thread

NAHWheatCracker

The "Always New Projects, Never Docs" section is something that I often point out to my manager. He uses other engineers at the company as an example of the best engineers during our performance reviews.

The "best" engineers are constantly on greenfield projects. They are quite talented, but they have it easier in a lot of ways.

- Working on projects with the most perceived value, so they have strong reasons to be motivated by their work.

- Using the newest technologies, so they don't get bogged down in technical debt. This can also be motivating for engineers.

- They have more autonomy because the product hasn't built any bureaucracy around it yet.

Most engineers hired in the past few years are maintaining the projects those engineers created 2 or 3 years ago.

The projects are never documented well. Technologies haven't been upgraded, so versions are out of date. Tooling was poorer years ago, so engineers have to fight that. Needs of the products have shifted and architecture hasn't. Refactoring is always on the back burner, so the problems persist and multiply as new features forced in.

The people who got to build the original projects years ago keep looking better as they build new projects today. Everyone hired since is mired in trying to keep the product running while adding new features. The result is a growing gap between the "good" engineers and the "bad" engineers.

The worst part of it is that if you point any of this out, you're essentially calling out the "best" engineers in the company.

When you get to build your mental model directly into the app, you're always going to be at a huge advantage when thinking about it.

As far as I'm concerned, a big part of my job is fighting my urge to do just that, and try to write code in a way that my coworkers appear to have a better time understanding.

This is the developer version of empathy. To even consider what it would be like for your future self to touch this code, or someone else to read or reuse your code is empathetic.

It’s understated and I think it’s the most important thing any developer should have. I personally don’t care about any other trait other than that at this point in my career.

I love to see it, and inspires me to up my developer altruism game. I’d love to see more interviews where people just hand someone not-so-perfect code and have them describe what could go through the mind of a variety of team members as they read it, and what could have gone through the mind of the person that wrote it, and finally what is forgivable.

If anyone reading wants a place to start, I think I started by realizing that I needed to write a lot more code than I wanted to attach my identity to. Start by writing the code that you would like to not have to be responsible for as if you expect someone else to be happy to take over, or at least not stressed or grossly disappointed.

Then if you can figure out that it's all 'our code', you can work from there.

> When you get to build your mental model directly into the app

Also, your preferred libraries, and the level of abstraction you are most comfortable with.

Personally, for now, I like being one of the "maintainergineers".

Often, when I read code written by "green fielders", I question their competence, and question myself why I'm still working at this place. I admit this says more about my ignorance than anything else. I'm just saying what I feel at the moment.

All projects that I have been part of in my current company don't have automated tests (at least initially before I joined). Instead we rely on QA. Since I read a lot about things like DDD / well architected code I often dream working on a codebase where implementing features and fixing bugs isn't frustrating and deploying to production isn't nerve wracking.

Since the first step of refactoring is to have tests, in my first project I endeavoured to have unit/integration/e2e tests. They're a bit subpar for my taste, and can be a bit slow to run at times. However, these tests allowed me to sleep better at night after each deployment.

In the last few days, since joining a new (EDIT: non-greenfield, as a maintainer) project, all I've done is write unit/integration tests. (EDIT: I'm writing unit tests to what I currently consider very sloppy code, e.g., not using dependency injection, leaky abstractions like calling request() inside a model class (project uses laravel framework))

I like to think that what I have done and what I'm doing right now will enable me to write better architected code. As an extremely simple example, I find it harder to test `new FooClass` than its dependency injected counterpart. I hope I'll remember that next time I write code.

> All projects that I have been part of in my current company don't have automated tests

On the rare occasions when I start on the green field, logging and unit tests are literally the first things I set up. It only takes a moment, and the time investment is paid back the first moment you investigate a bug.

Doesn't mean I do unit tests religiously, but at least I do them sometimes.

I would love to be a maintenance engineer in my current job, if it was respected. Sadly, it's not and project managers drive for features.

I agree that maintenance work is more likely to be instructive in creating well architected code. It has been a joy when it's possible to take a poorly build module, write tests, and refactor it into something simpler and more effective.

> Using the newest technologies

What's so good about newest technologies?

Every single time I tried to use them, I had to waste lots of time reporting and working around bugs in these technologies, and bugs in the surrounding ecosystem triggered by these technologies.

Generally, I prefer technologies at least 1-2 years old.

I would interpret "newest" as "latest best suited" technologies. Well vetted would certainly factor into that choice.

In other words, new projects don't start with any dependencies on tools that are no longer considered the best for the job at hand.

Yes, newest was probably not the best word for it.

The best technologies can be chosen, new or old.

How do you explain engineers who are great and motivated while working on less sexy work?

You can have great engineers in maintenance, I didn't say all great engineers are on greenfield work.

The ones working on greenfield projects have been the ones used as the bar to measure other engineers by, in my experience. This works both to glorify the greenfield engineers and hold back the engineers stuck in maintenance.

Motivation is very personal. Some people are motivated in everything they do. A lot of engineers are motivated by working on high quality code or new technologies. Others are motivated by perceived fairness in how work and rewards are assigned.

For those latter two sets of people, being stuck in maintenance and having greenfield engineers used as examples of how to be better can be demotivating.

Some people just love a certain legacy system (in the old days of more experimentation it was legacy hardware too) and want to be able to stay with it as long as possible.

This doesn't prevent them from keeping up with the latest stuff either BTW.

the ones with good pay check? /s

This is the trick, always pick the work that is relatively easy/has less unforeseen edge cases. Rapidly develop it before it becomes complex. Collect your pay checks! Theres no reason not to do this, life is short, just avoid the bad work at all costs.

Reply on news.ycombinator.com