Did you meet this moment where you were looking for a blog post you read about a topic but can’t find the hyperlink pointing to it? Did you ever ear about a new killer framework for your project but during a meeting were not able to get back its name? I did. From my point of view, developers should make technical watch (tech watch), share and save things they found, to avoid such situations. Let me explain why.
🌍 1 — Make tech watch to DISCOVER
People who have technical or creative positions (developers, architects, whatever you want) and also I think non-tech / non-creative people (project manager, team manager, etc.) should care about watch so as to discover things.
We are human (I hope) and by definition are curious: read articles or listen podcasts enables us to be more open-minded and to get rid of prism we have on some themas. By always crawling the same blogs we might be more narrow-minded or see problems and topics only with the same single point of view and horse blinders.
For example “why should I parse, as a developer, an RSS stream about ecology? My job is not related to this theme because I work on backends, not with koalas, no need!” That’s a first way to react. However if I spend some time to consume ecology-related contents, I may get a new point of view about some subjects I know. “Koalas may die because of the global warming due to too much greenhouse gases made by the coal-powered plants built to feed our datacenter using my not-enough-optimized backend. Oh crap, how should I make my code greener?”
Discover new things is cool. Read content from unusual providers to remain curious is cooler. Look for RSS feeder, tech-related or not web sites, or blogs of people outside your scope. You may find interesting things you can directly or not use afterwards. A good exercise is to talk to colleagues with a job far-away from yours.
Some examples of websites about laws, regulations, hardware, games, scientific subjects: Ars Technica, NextInpact, Numerama or The Verge. You can also go to events like Passage en Seine and listen podcasts like these in Artisan Développeur.
🎓 2 — Make take watch to LEARN
Tech watch is not hopefully a story of RSS streams, publications or other things to crawl with a cup of coffee. Tech watch is also about practicing.
We have the chance with the job of developer to have a massive bunch of communities all around the world. These groups e.g. like Android User Groups, Google Developers Groups, Java User Groups, and communities built about frameworks or programming languages provide a lot of meetups, keynotes, codelabs, or coding dojo. Going to one of these events allows you to try new tools you might use, and also meet people. By gathering people around a topic for a noon or an afterwork, these communities make the ecosystem more dynamic and living. They can also set up big events attending hundreds or thousands of men and women who want to discover new subjects with keynotes, or satisfy their curiosity with noon’s quickies, or try a new framework during workshops.
Making tech watch by talking to people and practicing with colleagues is a good opportunity to be aware of the power or the efficiency of this or that tool. Companies who do not let their collaborators go to these kinds of events, or who do not set up internally such events, are blinded and out of the game. And they might kill koalas for sure. By acting like this they refuse to make their workers more skilled or efficient. Ask to your chief if you may find a slot in the agenda to make a workshop. If the answer starts by “useless”, “waste of money, not profitable”, “not enough time” or “it’s not your job”, it may be the time to go somewhere else. Sometime you can see those kinds of companies complaining about the lack of talents or workforce. Hey, software / doers / makers culture or not?
Have a look on DevFests (powered by Google without chains or gags) or Devoxx for example. You should also keep an eye on Code d’Armor (no koalas but incredible seagulls), Codeurs en Seine, DevFest du Bout du Monde, DevFest Nantes, FOSDEM orLibre en Fête en Trégor… Yup I make my own advertisement, but it’s my blog ;-)
Communities may use social networks like Twitter and also Meetup to register their events. You can find here a Google Developers Group near you! You can also keep an eye on worldwide events like Apple WWDC, Google I/O or Microsoft Build.
🚨 3 — Make tech watch to GUARD
The last reason you should really make tech watch, and this argument should make your chief interested, is guarding. Guarding? Yep, guarding. Guarding from all crappy things which may come to burn your company, eat koalas or waste so much money. To my point of view developers are in the frontline of the tech ecosystem.
Thus if a critical flaw appears on, randomly, almost 100% of the sold CPU in the world, developers may be able to understand the huge quantity of problems which will fall. Other example, if a web giant is angry with another giant and removes its certificats from the store due to a misuse of user agreement, developers may be the most aware people and can warn their colleagues and chiefs about this problem which can be spread to all users. A last example, if a flaw has been found and perhaps with exploits on a library or a tool all projects of the company use, developers should be ready to evaluate the risk, to apply the patches and to warn. So let them enough time to read, check and react!
These examples above are not invented, they were true facts (from Ars Technica, The Verge, and Tech Crunch). Thus if your chiefs do not understand the gain to make tech watch, talk to them including money. And with koalas.
📤 4 — But how to deal with such amount of data?
Good question and I do not know the perfect solution.
Bookmarks of your web browser are cool, but with too much references it will be a pain. Some tools like Pocket can be efficient but never tried with a large amount of documents.
Using social networks to share content is a good idea, but choose the good tool. Some companies used places within Google+ to share data… woops, Google+ closed.
Sharing a spreadsheet? Ok but too much 90'.
Personally on my week-ends I implemented my own solution. A spreadsheet with its sheets exported to CSV, then parsed to HTML and JSON contents feeding my PWA with a Ruby web service. And a terminal so as to deal with the logic of my program without using a GUI. I had a lot of time to kill and it worked. Why not uploading the project on a server? Good idea.
As a developer you should make tech watch.
It is the only thing you should remember here. You have to do it. Your boss must provide you resources to make it. But a good tech watch is not done behind your own desk. You should share things you found with your colleagues. Go to meetups, attend to events, talk with people outside your scope. By essence we work on a fucking living world where each day new tools to discover and new rules to learn appear.
So think ahead, discover, learn and guard. And save koalas ʕ •ᴥ•ʔ