Introducing Tideway Engineering
In Tideway, the group of almost 40 people that designs, develops, tests, documents and maintains our software is called “Engineering”. In other companies it is sometimes called R&D or Development or something in that vein, but it boils down to the same thing: This is where a group of people ranging from the quite technical to the ludicrously geeky are entrusted with creating the product that the company publishes and sells. It is the heart of the company.
Being in charge of such a group is both a huge privilege and an interesting balancing act between what the business wants and needs and what we can do without shooting ourselves in the foot. Of course, the “business” always needs more features, more functionality, better performance, fewer bugs, sexier demos, more intuitive UIs, better integrations - and needs it NOW, or at least a little bit sooner than possible.
Engineers actually want those same things, but bring a different set of concerns to the table when it comes to setting the time table. They want to innovate, take the time to experiment with different possible solutions to the problem, figure out what the right technology for the job is, have some fun working on a whacky idea that may turn out to be very valuable, take the time to think about and discuss what the tradeoffs of various solutions are - and then implement the chosen solution properly, avoiding an understandable tendency to ship the first prototype that may demonstrate what we could do if we made the investment, but is not yet the solution.
In addition to developing the product, the team also keeps abreast of new developments such as new programming languages, operating system features, network protocols, algorithms, development tools, new or upgraded libraries, components, etc. Building up and maintaining a good library of such knowledge is a key ingredient in building products that are both interesting to work on and stack up well against what the competition is up to - and this is why we are here. Fortunately, most of the Tideway team consists of fantastically talented people who consider developing good software more than just a profession, it is often a hobby or even a passion as well, and so a lot of this work happens during what is sometimes euphemistically referred to as “spare time”.
One of the reasons why this is the case is that we are quite strict when it comes to hiring: we hire only the best, most talented and most engaged engineers, and try to avoid contractors. As most software developers looking for work are somewhere between astonishingly bad and mediocre, this is a big challenge that I intend to talk about in another post.
When you have this many bright people looking at a problem, it paradoxically becomes quite difficult to decide what to do next: everything seems possible, and there are so many good ideas floating around that it is tempting to try to do everything at once. Succumbing to this temptation and some avoidance techniques is something I am also going to explore in a future post.
When a team tries to do too many things at once, it invariably results in features shipping before they are ready; dealing with the resulting build-up of incomplete features implemented using undesirable hacks and architectural shortcuts is another post I intend to make.
Finally, one day I am going to write about the kinds of things it takes to keep a team that is as diverse and talented as the Engineering group at Tideway engaged and interested. It’s clearly my biggest challenge of them all, and at the same time is the one where the answer is the least well defined.
If you have a comment or an idea for a topic you would like me to write about, please drop me a line at a.mertner at tideway.com.
RSS