Before I start, I want to make one thing clear: I'm still on my journey, not even close to being a real "enterprise programmer" (as whatever you would define this). But I think I was able to make some neat improvements regarding my skill level.

My personal story

You probably don't care about that story, so you may want to skip directly to What it's all about.

When I started programming many years ago, I did it out of personal need and, even more important, interest. That interest in programming actually never completely faded, but it decreased after some time - especially when I started working full time in this area. I kind of felt fully occupied by my job and wasn't really working on personal projects anymore which in some way made me feel bad and sad. As mentioned before, the major point of pleasure in programming for me has always been my intrinsic interest in learning something new.

One thing I want to mention is that the agency that I work at grew quite fast. Back then when I started working there we mostly built websites for small, often regional, companies. Now we build fully integrated digital marketing solutions (*bingo*) for big national and also multi-national clients.

As with that change, the requirements also changed quite a bit. When we would simply hack together some websites the quality actually wasn't too important. Our customers had nothing to loose, we had nothing to loose and maintaining those sites was still easy due to their simplicity and small size.

But enough of that, let's finally dive into the real topic.

What it's all about

Probably the most important thing that I learned is that "enterprise programming" is a lot about abstraction. All the patterns and principles are just there, to make even the most complicated logic you can think of, easy. By using abstraction.

Want some examples?

Interfaces

Interfaces abstract the implementation details from the the caller.

Inversion of Control

IoC abstracts the object creation from the caller.

Repository pattern

Repositories abstract the data fetching logic from the actual business logic, that takes place in some business classes.

Now the big but: don't over abstract. If you can't come up with a good abstraction that you and your colleagues feel comfortable with, it may be better to not abstract at all. Sometimes no abstraction is better than a bad abstraction. And you can still abstract that part of code later.

Invest time in planning

So you may know that quote:

Weeks of programming can save you hours of planning
image by The Amazed Coder

There's so much truth in it. Small invest in planning brings great return. I agree with you that planning is boring and often annoying. But in the end it saves time and your nerves. You don't have to plan ervery single detail. That would obviously also be against the agile principle. But plan the features before you start implementing them. Your colleagues will thank you. And this also has one neat side effect: a documentation. Your colleagues will thank you, again.

Refactor early, refactor often

Refactor continuously. Because if you don't, you will have some huge problems afterwards. Believe me, we had to learn it the hard way.

So let's say you need to add some new functionality to some part of your solution. Unfortunately, the possibilites of extending that part of the application are limited. It's your choice to either quickly hack in that new feature and hope that nobody ever gets across that dirty lines of code you just wrote. And that nothing ever will need to be added there again.

Or you tell your project manager that you will need some extra time to refactor that area to be more extensible. Most (good) project managers don't only care about money or financial success, but also quality. And believe me, most clients do too. What that means? It's in 99% of all cases it's up to you to keep the code base clean. Because no time is no excuse for bad code.

Have a clear architecture

For me, a good architecture promotes writing clean code and forces following some basic rules, so that every programmer knowing the base architecture can a) find what he or she is looking for and b) knows where to put which kind of code. A good architecture also promotes using some common patterns that allow for separation of concerns. It's not always easy to introduce an architecture in an existing project though. In that case, you'll have to somehow find a solid middle way.

Use a good development workflow

We have a very simple but quite effective rule set:

All these points take some basic toolset for granted. You'll need to have:

Use pull requests

In open source projects they are pretty popular. For a good reason. Four (or more) eyes just naturally happen to see more than only your two.

Let your code be reviewed. Ask for comments, don't be shy. Accept criticism, it's a good thing. Of course, you should also review the code of others, it also helps you to understand the code and keep up to date with the code base. There are companies, where there is a "pull request master" (e.g. the lead developer) that reviews all of the code and merges it. I don't like that concept. It just throws away so much of the benefits that pull requests have to offer.

For more on pull requests I kindly refer you to better code reviews.

Share knowledge

Those are actually three points.

The first one is: share your knowledge. You know a lot. Most probably also many things that others don't know. Share that knowledge, with you colleagues or even the world - being it through a blog, voluntary meetings, user groups, conferences, a knowledge base... There are so many possibilities. Also, it helps you to improve your very own knowledge by diving deeper into specific topics. You found some cool library? Share it. You built something cool yourself? Share it. You've tackled a really complicated bug? Share it. It will help others.

The second one: encourage others to share their knowledge. It's just the same with others as with yourself. You can learn quite a lot from other people. Ask them to share their knowledge if they know a topic better than you do (e.g. through pair programming). Don't (really, please, never ever) think that you're superior to anyone and don't need no help. That's just insane. It kills so much potential greatness. Getting inspired is one of the greatest things.

And finally the last one: develop yourself. This kind of builds on the first two rules. Use blogs and books to get inspired and to learn new things.

Don't feel overwhelmed

So you may not have a cool title such as "Senior Solution Architect" or "Senior Development Consultant" (I myself don't have and want one either). But that doesn't mean you're not a good developer. Don't fall for impostor syndrome. The work you do is most probably great. The fact that you're reading a blog post such as this one shows that you're interested in developing yourself, so that makes you probably a much better developer than many others.

You also may not know the names of all those fancy patterns and principles (like KISS, DRY, YAGNI, ...). What really counts is that you know why they exists and how to apply them.

My personal story, again

Let's get back to my personal story real quick. I find it really encouraging to finally have found the pleasure again. I'm reading quite a lot, trying to improve my skills. I'm learning new things everyday and can look back at the mistakes that I made and reflect wisely on them. I know that today I could do it better - and often enough refactor these code smells that I introduced. Of course that also holds true for the mistakes that others did. Why shouldn't they be allowed to do mistakes?

Sure, some of this may sound like one of those fortune cookie wisdoms, but believe me, I'm serious about every single word.

Further Resources

Here's a (presumably incomplete) list of books, websites and blogs / blog posts that I encourage you to read because I for myself found them really really helpful.

I may add some more paragraphs from time to time, as I continue on my journey. Make sure to check back if you want to be updated.