There are some basic philosophies and ground rules I've found useful (this list will grow, give it some time :P)
give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime
I've always enjoyed teaching things. Simply put: I love learning new stuff myself and I am grateful for living in a time when almost every piece of information one can possibly dream of is out there. When figuring out a particular problem myself, there was often that feeling of "if only I had known 'x' four hours ago ..." and I'd like to spare other people that experience. On the other it gets better with every problem you solve because, well, most problems boil down to asking the right questions aka. googling the right stuff (which is one of the most valuable skills a developer has to master, imho).
I feel very strongly about not simply presenting the solution but explain the way you got there. Chances are, you'll encounter a similar problem at some point in the future and I would rather give you the necessary tools to figure it out yourself than solving it for you again.
I can't manage what I can't measure.
One accurate measurement is worth a thousand expert opinions.
These are big ones. If you're coming from a mindset of "always learning", you'll embrace the philosophy of "The more I know about X, the more I know that I don' t know X" at some point. You'll start to constantly question your work (and that of others...) because you are used to the fact, that there seldom is one truth and the more you get to know about a topic, the more likely it is that you'll have to change your opinion on something.
Combine that with highly complex fields and black box components (think AI, Attribution Modeling, Re-engineering Google's ranking algorithm) and you'll quickly notice, that there are perfectly reasonable assumptions that are still completely incorrect. It does not matter how you feel about something or how much you think you are an "expert". Unless proven, that really does not count much. I'm not saying there is no value in an experts opinion, especially if the one having it has a lot of experience in the field at hand - that's still super valuable in terms of developing a hypothesis.
But in the end, numbers and metrics are your one, true friend.
An ounce of prevention is worth a pound of cure
As a software engineer, you're probably familiar with "the cost of a bug":
After realizing that, the phrase "... but we didn't have time to write tests!" becomes almost comical. Making errors is human. Things break, that is absolutely normal. But isn't it so much better to see that immediately instead of " crossing-fingers and hoping that nothing breaks - and if so that no one notices" ?
Open Source
I am a big fan of Open Source Software. Not only because it provides priceless software for free, but also because it is a great resource to learn and develop. Developing OSS basically means to deal with a potentially infinite pool of developers/contributors all across the world as well as managing and prioritizing feature requests and bug reports of actual end users.
To make this even possible, you must introduce a certain level of automation and quality assurance, which ultimately leads to becoming a better developer automatically. Examples include:
- solving onboarding issues
- provide reproducible environments (vagrant/docker)
- automate common actions (composer scripts/Makefile)
- aligning multiple developers
- enforcing code style (.editorconfig, .gitattributes, PSR-2)
- bug / code smell prevention (code linters, static analyzers)
- provide git-hooks
- building continous integration pipelines
- set up multi-level testing structures (unit/integration/end2end)
- automatically check pull requests (jenkins)
- provide code metrics (code coverage, cyclomatic complexity)
- writing documentation
- semantic versioning
- code deprecation strategies
- ...
In the end, this is the same set of skills that I would expect from a great inhouse teamlead of a software engineering team. But it's actually rather the exception than the norm to meet such developers in my experience (I interview up to 5 developers of all levels [junior, intermediate, senior, lead] per week).
Projects that I currently support:
- paratestphp/paratest
- Framework for the parallel execution of PHP test suites
Short facts
- 2006: Began to code (HTML, CSS, PHP, MySQL) including SEO
- 2008: Started studying Applied Computer Science via SAP at Duale Hochschule Baden-Württemberg in Karlsruhe
- 2010: Spent 3 months in the SAP research center in Palo Alto, California
- 2011-01: Launched first software product in the SEO industry (Article Wizard (german))
- 2011-09: Bachelors degree (final grade 1.1)
- 2011-12: Voted Best SEO Newcomer 2011
- 2012: Started working as SEO consultant at TRG (The Reach Group) in Hamburg
- 2013-01: Started lecturing at AFS Akademie für Fortbildung in Suchmaschinenoptimierung ( twice per year) on the topic of "Pagerank und Trustrank"
- 2013-05: Started working at Tchibo GmbH as Technical SEO Manager
- 2016-04: Started working at About You SE & Co. KG
as Lead/Head of Marketing Technology
- 2017-07: + Head of SEO
- 2017-12: + Head of Webtracking
- 2020-03: Technical Director Marketing Intelligence and Technology
Slightly longer
Just go over to my LinkedIn profile