Hacker News Reader

Comment by mgomez | Hacker News Reader

> Bob did well on our interviews and was hired as a software developer in charge of infrastructure components. But it soon became apparent that his development habits were very heavily biased towards the hacking end of the spectrum.

I'm primarily a self-taught developer. Can anyone recommend some resources (e.g., books about professional software engineering practices) so that I don't end up like Bob?

View on HN

"Bob"'s problem was counterproductive pride and being unteachable. There is no room for ego in a precise profession like ours, and none of us writes perfect code. If "Bob" had learned from his peers during code reviews, he would have been fine.

To answer your question: The Pragmatic Programmer by David Thomas and Andrew Hunt, Writing Solid Code by Steve Maguire, and Code Complete by Steve McConnell.

There is no book to teach these parts. Books teach some simple principles but there are many right ways to write code. Ask your manager and coworkers for real feedback. Let them know that you can take anything. It even set up some anonymous feedback method. And no matter what they tell you don't get defensive. Just say thank you for the feedback and reflect on it later. You can even get mad later but still please try to see it from their side. 99.99% of people really are just trying to help you. Last look at how coworkers are writing code and how they are solving problems. I still learn daily from reading others code.

I totally agree with learning from others do but I don't think you'll get too much use out of asking for honest feedback.

Either people won't trust it's 100% anonymous, won't see an upside for themselves or maybe bad actors.

Regardless of whether you're self taught or minted from a program, the lesson to learn here is that your colleagues can get rid of you if your work doesn't conform to their expectations.

It's just as possible that Bob's colleagues were anally retentive simpletons that couldn't handle the truth of his code, as it is that Bob is a loosy-goosy house of cards coder whose results were always C- material (I've worked with both.)

Point being, if you want to keep your job you should aspire to be a good 'culture fit' and if you want to be a good developer then work with great people and read more source code than you write.

There are plenty of good books, but IMO the problem with Bob (and the thing to keep in mind not to become one) is that when the company tried to help him, he not only resisted, but effectively sabotaged this.

Books are good, but if you are new at the company or do not know how it works, find a few more senior folks who are doing well and ask them for advice. Run your architecture / solutions past them, ask for opinions, etc.

I think a vast majority of folks fired like Bob just did not listen to strong, non-subtle signals from the company trying to prevent the firing. My 2c.

I like Code Complete by Steve McConnell. It was popular at Microsoft when I worked there in the late 2000s.

I re-skimmed it recently, and it still held up, but the advice has influenced a lot of other writers so it may not feel as profound as it was then, but I think it's sound advice in terms of software craftsmanship.

It's also worth noting that Code Complete biases toward processes that work for a large company where there's lots of cross-team collaboration. The advice is good in general, but you should weigh certain parts less if you're working on a smaller company and especially a fast-moving startup.

Also Joel Spolsky's blog is fantastic.

Build a medium-sized project on your own, especially one with evolving requirements. Bonus: come back to it 6 months later. You'll learn about scaling a codebase past 1000 lines (and maybe 10,000 lines), weigh the pros and cons of hacky workarounds, go through the pain of refactoring, and gain perspective about how projects evolve.

Code quality can be a religious issue for some people, and some teams have somewhat strange ideas on the subject that they've agreed to agree about despite the ideas not being reasonable or valid.

Perhaps Bob was an engineer with a long record of success in other teams, who was surprised and justifiably defensive when his colleagues weren't happy with his work and demanded he do things differently for vague reasons that didn't make sense.

He's probably much happier now that he's in a more compatible team. Perhaps he's the guy in the photo.

Reply on news.ycombinator.com