Hacker News Reader

Comment by vfc1 | Hacker News Reader

This is great stuff. Problem is there is the work the company needs you to do, and the work you want to do.

Both of these change overtime, for example in software development when the lifecycle of the project advances. As the project reaches maintenance mode, you can no longer design the architecture and implement things from scratch, its already done.

So the work the company needs you to do now is very different.

Then there is your personal preferences that change over time.

So the work you want to do and the one the company wants you to do will probably only overlap for a short period of time.

View on HN

> So the work you want to do and the one the company wants you to do will probably only overlap for a short period of time.

Similarly, there's only short period of overlapping of the work you want to do and the work doing which you would grow. I see too often programmers jumping around abandoning their half-written application or library once it is somewhat working, never learning what semantic versioning is about, what it takes to write good documentation, or how architecture works.

I've seen people proud of having an opportunity to maintain (note: not to develop, just to maintain) big products. Such product was doing amazing things and was well-written, of course, but would you think you could take pride of maintaining somebody else's work?

I can easily imagine taking pride in maintaining a well-written project doing amazing things. I believe most people unhappy with maintaining someone else's work are dealing with neither, and are furthermore discouraged from doing anything to make it better. Just complete the tickets as quickly as possible, and keep your head low.

Yes, but you wouldn't know in advance that this codebase you're going to be assigned to is well-written, or that it does amazing things (unless you're in its target users group or know the target industry already).

If somebody offered you a job to merely maintain an old, gigantic codebase, I don't think your first thought would be "wow, I'm going to learn so much from this!", and there probably wouldn't be any way you could assess the codebase quality before accepting the offer so you could end up thinking that eventually. This is how things that you want and that could help you grow can be vastly different.

I mean, if you're a novice, it should be your first thought. If it isn't, I consider that a failure of education. Jumping into writing something from scratch when you're not part of the target user group or know the target industry already is a great way to produce horrible code that you (or someone else) will hate to maintain.

This is why it's so important to grill your interviewers about the reality of working at the company, although I'll admit that I learned which questions to ask from bad experience. Asking those questions also happens to serve as excellent signalling to your technical interviewers, much more effective than being able to solve some silly logic puzzle.

And to be perfectly fair, you do learn so much from working on poorly written projects that are a horror to maintain. Failure teaches you which mistakes to avoid next time.

I'd love to hear which questions you ask in interviews to get this information out of the interviewers!

Ask them the questions you'd want to know answers to if you were hiring them, to determine their own merits. Insist on talking with the people you'll actually be working with. You want to know their opinions on programming paradigms, and design patterns. Ask about operational details like version control, code review, and releases. Ask about the history of the code base, who wrote it, where are they now. Ask how documentation is created. There are so many things you can ask.

Good code is surrounded by good processes. Ask about the processes that lead to good code. This not only susses out what the situation is on the ground, but also demonstrates your own quality.

> failure teaches you which mistakes to avoid next time

As a recent grad who has been fired from two jobs, I would be afraid to join a poorly written project because I would worry that I would fail and then be fired.

Learning how to be successful is pretty important and teaches you things you cannot learn from lurching from failure to failure.

Even the jobs with poorly-written codebases teach you a lot. Only they're teaching you through experience what is or isn't maintainable.

Sure, but at a certain point, you need to learn a method to writing a maintainable codebase. Otherwise you never become capable of building a successful project.

How did you fail?

> I learned which questions to ask from bad experience.

Would you mind sharing your best, most probing questions-- the one's that proved most useful cutting through corporate posturing and BS?

Maintenance isn't that significantly different from development from scratch. The differences are only in how it's paid for and how you evaluate risks.

Development from scratch means much more ... "sales" overhead. Meetings and (ultimately) disposable documentation.

I have just inherited a relatively poorly written application in a new job. I am going to take pride in optimizing it so the pages load in less than a second (some are timing out when there are other users on the system), clean up the crappy bits and make it more maintainable.

Sure its no as nice as getting to architect a whole application from the ground up. But the database seems well designed, so it shouldn't bee to much problem to make it faster and prettier and cleaner code.

>I've seen people proud of having an opportunity to maintain (note: not to develop, just to maintain) big products. Such product was doing amazing things and was well-written, of course, but would you think you could take pride of maintaining somebody else's work?

Most developers wouldn't. There's a stigma against maintenance. Most developers want to be Software Architects! (Said with the pigs in space voice).

As someone who's been doing mostly maintenance recently, it's pretty clear why:

1) reading a pile of code and trying to figure out how it works and being constrained by someone else's solutions is considerably less fun for most developers than writing something new and making decisions about how the system will be put together

2) It's much harder to point to what you did or talk up your accomplishments. Particularly to management.

You forgot the bit where you often get blamed for the consequences of decisions you didn't take that are firmly cemented into extant code.

Re 1. I think it's actually quite fun to take a piece of code, understand it and change it to meet new requirements. There's a good healthy challenge in that. I think a big part of the reason devs hate it is because they can't read code well. They can write it, but not read it. (I realize I'm generalizing, but it is based on some experiences.)

Re 2. This is very true.

Not to mention that all of the praise for the project has already been given out. All that there is left is angry users yelling that something isn't working now. It's a pretty thankless job.

1: it can actually be a lot of fun if you look at it as a sort of digital archeology. You are exploring an ancient world! I enjoy it.

2: write reams of documentation for every function and module and service you decode, check them off on a checklist, and point out how you generated x pages of new docs and analyzed y% of a previously mysterious codebase. Then when you refactor, you get to point out how many thousands of lines of obsolete PL/SQL code you replaced with 10 lines of Ruby.

I would gladly maintain the code I wrote in the past 6 years. I would love to maintain the codebase of at least one of Google's internal projects I had the fortune to work with. Thanks Google, their thorough review process and their focus on readability.

I would not touch with a ten foot pole the code churned out by AgileSprints(TM) held by computer-illiterate management to hit some arbitrary deadline.

The stigma is on shoddy code, which, alas, seems the norm in large swaths of our industry.

Reply on news.ycombinator.com