brainbaking/a-decade-in-the-industry.md at 9ea0e942feba4ab95081561ea63b088b0070b876

16 KiB

Raw Blame History

title

date

bigimg

subtitle

A Brief History

Before getting down to business, it might be more appropriate to frame my experience first, by explaining how I ended up not working for the industry anymore. My first job with a major IT consultancy firm as as software developer took quite a while and lasted 7 years. When I started looking for other opportunities, recruiters were astonished: "wow, you stayed at one company for 7 years?". The current job hopping trend makes me sad: to me, switching every year might damage your CV instead of enrich it. We did consultancy work, but were always outsourced as a team. That makes a huge difference. I've learned a lot in little time. After getting tired of commuting too long, I switched from consulting to in-house product development and stayed with my second employer for 4 years.

I've had a lot of different roles, even if my title mostly stagnated at "software developer". Cooler colleagues made theirs "engineer" and prefixed it with "enterprise" or "senior", that always works. My experience can be roughly cut up in these different stages - I'm sure you'll recognize them. If you want, you can map these to the Dreyfus model, or any other learning model.

Stage 1: Ignorance. Soak up as much as you can, because you don't know how anything works. This took 4 years. Yes, 4 years. My Master education took that long, and after graduating, you still have no clue. Does this sound bad? I was a (junior) developer.
Sage 2: Competent. You're getting the hang of it: you start to easily recognize code parts that need refactor work, you've gone wide by exploring all possible kinds of technologies and gone deep by really, really knowing something well. Another 2 years pass by. I became a (senior) developer.
Stage 3: Expert. People go to you if something has to be debugged. You create courses, do technical interviews, help others grow and enjoy the ride. Things are getting boring: you identify problems with your eyes closed. So you're seeking challenges elsewhere: in collaboration. Another 5 years are gone. I was a coach, architect, developer, ...

In stage 3, I discovered I like teaching others what I taught myself. In fact, I liked it so much that I started (this website? and) giving guest lectures in colleges and universities, ultimately translating into a full-time switch from industry to the academic world. Figuring out how patterns work for me was one of the most satisfactory challenges I faced while co-developing enterprise software in agile teams. But once you see through the (in-)differences between tools, languages and APIs, repeatedly applying them made the jump easier for me - towards ideas and concepts instead of application.

So, What did I learn?

Not one person working for 10 years in the IT world will walk the same path above as I did: different backgrounds, education, interests, domain, company culture, implementation practices, ... So take my advice with a pinch of salt as it's personal and might not help you very much. My academic colleagues are curious to hear about my experience "in the field" and I hope to inspire one or two, but it might also be enlightening for the lunatics I've shamelessly left behind (tirez votre plan!)¹.

1. Go Wide & Go Deep

I'm a big advocate for generalism as I've written in the about me page. Being a Polymath or a Renaissance man as enriched my world in so many ways I cannot even begin to imagine what it would be like if I was only interested in a few subjects. Be open to anything. Don't limit yourself to one programming language: do yourself a favor and learn as much languages as you can manage. Cross-pollination is extremely important - not only in (software) engineering, but in life in general! So don't limit applying these principles to programming, but learn from other domains as well. Try a psychology course, read some philosophy. Get your hands on anything you don't know anything about. This not only broadens your own knowledge, but feeds those serendipitous connections. Get to know a lot of things. Keep on wanting to know a lot of things, again and again. Build a samurai learning mindset.

Study the science of art. Study the art of science. Develop your senses - especially learn how to see. Realize that everything connects to everything else. - Leonardo Da Vinci

That's not to say that specializing isn't bad: in fact, it's the default way to go in IT. Just make sure you're not in so "deep" that you can't get out! Be the best at something, and the worst at something else. Are you learning JavaScript? Great, how about digging deep and really, really knowing how prototypal inheritance works instead of only being able to apply it's patterns? Did you take a look at the V8 source code? Can you learn anything from contributing to the React Github repository? Get to know something very well.

2. Fail Fast & Fail Often

I'm sure you're familiar with the agile "demo or die" principle: if you can't show what you're working on every few weeks (iteration), we'll cancel that project of yours. As simple as that. Forget about specifications, Gantt charts and R4 models: don't just stand there, do something! Launching something means getting something in the air, as soon as possible. I've sworn by Test Driven Development and Continuous Integration & Deployment since then. Unit tests save lives and keep my brain sane. Software development is incremental development.

If you're not failing every now and again, it's a sign you're not doing anything very innovative. - Woody Allen

However, sometimes, you need to stand there, don't just do something. With complex pieces of software, refactoring in a new requirement comes with two pathways: that of least and of most resistance. It's obvious which is easier for you to go with, but that doesn't mean you should blindly act. Think, talk to others, turn it on it's head, approach it differently and come up with multiple solutions. Then pick one and go for it. Remember to let it fail first. A word of warning: failure can be painful and frustrating. You need to learn how to be resilient before - to be able to get up and do it again.

3. Work with People, not Technology

"Engineering" software is hard: there's no clearly defined set of requirements, implementation patterns change and shift frequently as do API's and languages. But Creating software is first and foremost a social practice. Teamwork is obvious, but working across teams, across divisions, talking to customers, owners, business experts and devOps means even more contact with others.

People who join a social practice gradually adopt shared values and strive for standards of excellence defined within it - Alasdair Maclntyre, After Virtue

Some developers might not like this, but we have to face the facts and admit that social skills are as least as important as technical ones. How many times did you witness a software project fail due to technical issues? And due to miscommunication of some sort? Right. Being open to anything (go wide) also means being open to others as they are usually the ones who surprise you the most, you learn from the most and you can rely on the most! Software development is people development. This is not by chance the subject of my doctorate.

First, motivate and inspire yourself to do something great - something hard that demands the most of your abilities. Intrinsic self-motivation always pays off in the long run, don't get fooled by money or fancy cars. It's easy to fall in that trap, but after a few years you'll notice it will become harder and harder to motivate yourself to even get out of bed. Keep a journal. I cannot express in words how much that helped me to keep pushing myself - and in the end, others.

Then, motivate and inspire others. Remember this order: if you're not motivated, you will never be able to inspire someone else to do the same! I love inspiring others; this is my number one reason to do whatever I do. This is the reason I'm writing this, the reason I want to teach, to talk about good books I've read, to convince someone to follow that course that helped me so much, ... And it's amazing how much energy this gives me - given that others are willing to receive.

As soon as you seek to inspire others, it inspires the best in you. - Brendon Burchard

To inspire, you share information. You never withhold information! Remember you're working together, nobody is going to steal your job, you're not going to get fired, and you can even try to convince your company to publish small modules open source as a means to give something back to the community or even to make a name. Sharing is indeed caring. This doesn't stop with code or domain knowledge! Share as much as you like to inspire others. Share articles, buy books and give them away, bake cookies and bring them to meetings, ... This has a huge impact on the bond between you and your colleagues and will make the crucial difference between team member and friend.

5. Ignore Ego's

Working with others can be very tiresome at moments, especially if someone sees his or hers work only as yet another career opportunity. Boring chit chat about ladder climbing, money and company cars make your sandwiches hard to digest during noon. Some people are simply too stubborn. I love an emphatic approach but my daily limited willpower resources are drained very quickly if people like these ruin the peace. Whatever you do, do not go into their advances. Ignore ego's.

It's a trap! - Admiral Ackbar

Try to protect yourself from these leeches by promptly blocking their train of thought, changing the subject or simply moving away. I've come across more than a few of these, it's very sad to see the software engineering field being riddled with cowboys, money makers and assholes. I suppose you'll encounter these in any field. The best piece of advice is to try and surround yourself with people who are brighter than you, people who also value the same things as you do. Not everyone can be changed that easily, sometimes it's not worth your effort. Oh, and delete your Linkedin account.

6. Sometimes, Grass Is Greener

Things might start to be a drag, and you might wonder, "what if I got to work in company Y, maybe things will be better there...". The answer usually isn't that one-dimensional: sometimes it is, sometimes it isn't. But that should not hold you back from taking a peek. The moment you get up in the morning and don't feel like going to work, you shouldn't immediately resign but try to figure out why not. If the answer is something substantial, it might be worth to still do so.

Never waste your time trying to explain who you are to people who are committed to misunderstanding you. - Unknown

I'm not a fan of job hopping, and I never will be. But I've been in some really, really shitty teams, and in some really, really great teams. If your critical mass is too small (say, like, only you?), you're not going to make it. Don't keep on hoping for the best. Sometimes, it's better to cut your losses and go. I'm not saying you shouldn't try - you'll notice soon enough if there is any hope left.

7. Read, and then Write

A good writer needs to read first in order to work in the literature. The same applies for a software developer: developers are first and foremost readers. Being an author comes in second place. Therefore, keeping things readable will be your primary objective. Practices like Clean Code and Test-Driven Development will help immensely to achieve this objective.

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” - Robert C. Martin, Clean Code

But reading shouldn't be limited to reading code or reading within your own subject domain. As stated before, being open to anything also means reading more on new and exciting subjects, which generates unique ideas and peaks your interest. Writing about something in detail is one of the best teach masters that forces you to look at things from another direction. Keep a Wiki, write Blog posts, track your notes, add remarks to Evernote. Anything to keep ideas and knowledge flowing.

8. Be Creative

There are multiple books about "how to be a better programmer": the productive programmer, the pragmatic programmer, the passionate programmer, ... But there's surprisingly little said about the fact that you're creating something. To create could mean to have a plan (analysis) and simply execute (code) it. It could also mean to approach a problem holistically, to come up with a multitude of possible solutions and to deliberately pick the best possible fit. Creating with uncertain requirements can be scary. Who knows what will happen. I know what will happen if you don't: nothing.

The human spirit lives on creativity and dies in conformity and routine. - Vilayat Inayat Khan

Being creative does not necessarily mean drawing on paper - but that does help. For me, it means coming out of your comfort zone and trying something new. Combine things that shouldn't be combined. Execute your ideas, don't simply collect them, even if they turn out to be nothing, I bet you'll have learned at least something. I bootstrapped Brain Baking thanks to a lot of previous (failed) efforts.

9. Be Reflective & Productive

Thinking forward is okay, but remember to hit the breaks and shift gears to think backwards for a while. When you take notes, are you re-reading them? And how often are you doing that? Your creative process will wither without a reflective approach. Think about what you're trying to do, about what you've done and about what you'll do. Act, and modify accordingly.

Men should pledge themselves for nothing; for reflection makes a liar of their solution. - Sophocles

Retrospectives shouldn't only be held at work to help improve your team's or company's performance. They can also help yourself. Why would you limit yourself to using things what they're made for if they can be used in another setting? If you're writing code daily but you find yourself copy-pasting a lot, did you know that clipboard utilities can enhance your workflow? (Just as a means to be more productive, not by embracing copy-paste programming! First understand, then reproduce.) Are you thinking about how to do something better? Do you bother learning keyboard shortcuts of your IDE? Do you think about how to dice your onion the most efficient way on your cutting board? You should.

What about applicability?

It seems like these "rules of thumb" aren't limited to just software engineering. That makes them all the more important - and transferable to a new sector and a new challenge. The article might have more appropriately be titled "what I've learned in life so far". After all, what's the difference between work and life?

Remember guys, I miss you, I'm just trying to be funny here! ↩︎

16 KiB Raw Blame History