Full Stack Toronto Conference 2014

IMG_0871

We at IBM are not strangers to large, well capitalized conferences. As things go in the conference-industrial complex, it is a big deal when one of your keynote speakers is Kevin Spacey, or Imagine Dragons entertain you after hours. So to say that the first Full Stack Toronto Conference was on the opposite side of the spectrum would be an understatement.

How about ‘no food’, ‘no drinks except coffee in the morning’, and ‘no entertainment’ of any kind except finding parking around Ryerson University building? OK, not fair, there was a get together in the nearby Irish pub the first night that I didn’t go to because I was tired.

This conference was really just a meetup making the next step. And on a weekend. Starting on 8:45am. Who does that? Our keynote speaker Anila Arthanari, Director Of Software Development at Infusionsoft, wore a t-shirt ‘I am not a morning person’ expressing the mood of most of the audience. By all accounts, this was supposed to be a flop.

And yet. When you peel the layers of conference pageantry, what remains is the kernel of it all – good talks. When talks are good, people will not mind walking out to a nearby panini store to buy lunch, or walk a block up the Church Street to get a Starbucks hit. Nothing matters if talks are good.

And they were. We had multiple tracks, and I could not go to all the talks, but those I attended were very informative, thought-provoking and immanently applicable. After every talk I had tons of things I wrote down to try after, or catch up on. So what were my key takeaways from the conference?

  1. Lots of people use Angular.js. If you need a client side MVC, you can do worse, with a caveat that version 2.0 is on the slowly approaching horizon, and to say that migration will be interesting would be an understatement.
  2. More and more people use Browserify over RequireJS. Put off by weird configuration syntax, and feeling the need easier code reuse in the case of Node.js, people seem to prefer to just ‘require’ their modules. It makes it easier to go back and forth. I am definitely going to try using it soon. This blog might help as well.
  3. Micro-services are everywhere. In the tongue-in-cheek ‘Show Us Your Stack’ track, multiple presenters described their journey from monoliths to micro-service systems. I like how people are now past the hype and deep in the gory details on standing up such systems in practice. Many were openly asking the audience for their feedback and red flags if they see any.
  4. Not everybody uses Angular.js. I know this is a contradiction, but people who value control and being able to grow into a client side MVC still value Backbone.js and its modular approach. If anything, Angular.js 2.0 promises to be more modular and less arrogant, for the lack of a better word. Here is hoping that in the future, considering Angular.JS will not be such an ‘all or nothing’ dilemma.
  5. Isomorphic and ‘federation of single-page apps’ is a thing. I thought I will be the only one pushing for rendering stuff on both the server and the client using the same templates, but Matthew Conlen from New York Data Company talked about exactly such an approach. Personally, I find it funny that people are happy to partition the API space into micro-services, but don’t feel the need to do the same with the Web apps. As the system grows, a single one page app providing all the UI is going to be the bottleneck of the system. Which is ironic, because user interfaces are the most transient and need to be evolved at a rapid pace. In essence, we are creating a system where API services can move at a rapid speed, but the UI is one big ball of MVC mud.
  6. React can help with isomorphic. Once you decide rendering on both sides of the fence is important to you, React is an attractive proposition because it can do exactly that, and plays nice with Node.js.
  7. Internet Of Things is still in its infancy. It seems like we all feel this weird excitement over turning the lights with Node.js apps and sending messages to robots and receiving MQTT messages that it is now 24C in the room. It is apparent that all this stuff will matter one day and great things will come, but I don’t see what to do with it today other than marvel in the possibilities. I guess once somebody does something really awesome with IoT, we will all slap our collective foreheads and say ‘but of course, so elegant’.

By the way, yours truly presented as well. You can see my slides up on Slideshare, and the source code of my demo on GitHub. You may find it interesting – I got Angular.js to fit into the micro-service driven Web UI, use normal URLs (no horrible hashes or hash bangs), and share a common header with other pages. I also demonstrated SSO using Facebook as the identity provider, lively UI using Web Sockets and isomorphic approach using Dust.js rendered on both client and server. The best part was when an audience member posted a todo into the demo running live on Bluemix, and his entry popped up on screen as I was demoing it. Audience participation, live demo, unexpected proof that the code actually works as designed – priceless!

So there you have it – you can make the attendees feed themselves, only give them coffee in the morning (what is life even), and dispense with most of the usual conference perks, and they will still come if the talks are good. I would say that the first FullStack TO conference focused on the most important thing, and succeeded. Good talks first, creature comforts to follow – good priorities in my book. Looking forward to the next year!

© Dejan Glozic, 2014

The Rise of the Full-Stack Architect

Pebble stack, Wikimedia Commons, Zzubnik
Pebble stack, Wikimedia Commons, Zzubnik

Full-Stack Web Architect needed with the experience with web services, back end Web platforms, databases, cloud based hosting such as Heroku and AWS, visual design, UX/UI, experience of mobile web development, all in agile environment.

 

An actual 2014 posting for a job based in London, UK

Ta-da – the moment has come. In post #2 of this blog, I promised to formally apologize for calling myself ‘an architect’. Only 39 weeks later, I am making good on the promise. Procrastinating much?

The hate on architects ebbs and flows, but never fully goes away. This creates a horrible problem for experienced developers who are fascinated with technology and are not overjoyed with becoming managers, yet clearly need to be in a leadership position of some kind because they are kicking them out of the developers’ kindergarten (what do you mean I am too old to hang around the playground, and why is it ‘creepy’?).

Management has been a traditional career growth path, and some still believe it is the only smart choice for former developers (kids, if you never before saw click bait, here it is):

From my chair, everything points in a different direction. Wherever I look (including my own company), hierarchies are being flattened, leading by example and by inspiration is replacing pulling the rank, and some companies are eliminating management altogether. So management is receeding as a leadership model to aspire to, but architects are being openly mocked:

So what is an experienced developer with so much to offer to younger colleagues to do? Looks like we are stranded between Scylla and Charybdis of the software leadership career paths. But it is a false dilemma. Bill was clear about this in his blog post – you should aspire to be a leader, to have a vision that inspires people and makes them follow you of their own will, not because they report to you. Somebody else can handle TPS reports, and you can focus on leading a growing group of people in making awesome products, and enjoying coming to work every morning because working in such an environment is intoxicating. Then you move the hell out of their way and let them do the work – they can do it better than you anyway.

OK, figured it all out – have a breathtaking vision, generate a growing following, solve the world hunger, and still have time to catch up on the new episodes of Silicon Valley on HBO. Got it.

Meanwhile on planet Earth…

For us lesser souls, some more attainable pointers:

  1. Be a wise sage – your experience with waves of technology allows you to notice repetition – new generations of developers re-solving problems from 5 or 10 years ago. When a puppy developer comes to you with a very cool client side MVC framework, point at the geological layers of MVC in the past technologies. Do that not to disparage the new framework, but to look at it for its own merit, not because MVC is a revolutionary new concept (you will know it is not, but chances are your junior colleague will not). Warning: don’t be an old fart for whom ‘things are not as good as they used to be’. That’s nonsense – a lot of things are many times better now, so be on the lookout for the first signs of being stuck in your own ways and nip it in the bud.
  2. Look over their heads into the future – there is always so much to do every day, and so few hours before your caffein-induced code turns into garbage. Allow developers to code like beasts, solving the ‘now’, while you look ahead, planning where you need to be in 3 months, 6 months, a year. Don’t try to go too far – we are all in a transition, and things are insane now.  Long term predictions have become somewhat useless lately, so ensure you have enough vision to prevent the team go idle, and be prepare to tweak the vision when course-correcting data becomes available.
  3. Resolve technical disputes – as fiery technical debates would indicate, there are many ways to skin any technical cat (a metaphor, I don’t condone skinning actual cats). One of your key jobs as a technical leader is to ensure the entire system works, and that can only happen if all the parts of the system speak the same language to each other. In other words, as long as everybody uses the same protocol, and that protocol does not suck too much, it is better than when parts of the system use superior but incompatible protocols.
  4. Prefer practical over pure – architects are often derided for making everything more complicated than it needs to be. Don’t do it. Look at the most popular APIs today – they may not satisfy REST police but they are clean, they work, they are stable and well documented and the deviations from the ideal actually solve some real world problems for developers.
  5. Maintain street creed – you can only lead developers if they respect you as one of their own, and that can only happen if you continue to code. Don’t put yourself on the critical path because you will spend too much time heads down, which will prevent you from doing (2), but you need to know what you are talking about. That requires that for every library or framework or protocol you want to recommend, you need to educate yourself, write some real code (sorry, more than just Hello, World) – give it a serious test drive.
  6. Don’t practice drive-by architecting – nothing irks developers more than an architect that designs a system, provides all the specifications, drops the finished docs on their poor heads and disappears, leaving them to suffer from the consequences of the poor choices. You need to see your architecture live in the running code, solving problems. Nothing makes me happier than developers gobbling up the new architecture and moving to it as fast and they can because it addresses their long standing problems. As a colleague of mine would say ‘the devil is in the pudding’ – if the system using your architecture is not faster, more scalable, more maintainable, your architecture sucks.
  7. Be a connector – just because people don’t officially report to you, it does not mean that you are free from practicing your soft skills. You need to talk to design, engineering, operations, product management – all speaking their own distinct languages. More importantly, you must be able to do it without strangling somebody with a Cat 6 cable. That privilege is reserved for developers, you need to be above it.
  8. Have cloud, DevOps and Web-scale in mind – practically all modern systems today are distributed systems running in data centers. They need to be evolved using Continuous Integration, features need to be promptly deployed using Continuous Deployment, services need to be clusterable, scalable and redundant. Architecting a system today without keeping these in mind is a recipe for a career spiral of death.

If you follow the suggestions above, you are really ‘system-developer-in-cheif’. Note that you are not a team lead even though it may sound like it – you are a ‘system lead’ serving a number of teams that already have team leads. You are a ‘how everything fits together lead’, which is too long to write, so for practical reasons, we will call you an ‘architect’. There – we closed the full circle.

What about full-stack?

In the olden days, developers have been segregated by their skills, because different tiers of a complex system were build with such a divergent technology that it was really hard to keep it all in your head. SQL experts were not very good at building backend systems with SOA and other bloatware, which was very different from writing Web sites with server-side MVC, which was very different from client side Ajax. Conversely, architects followed suit – they specialized as well.

With the dawn of the ‘JavaScript everywhere’, with NoSQL databases storing and passing around unstructured JSON, Node.js servers with JavaScript templating engines running on both sides of the fence, and MVC client libraries, a developer can theoretically write a whole system – soup to nuts. I say ‘theoretically’ because while the language context switching has been removed, the problem domains are still very different. There is actually a growing need for a breed of architects to ‘make sense of it all’ and devise and evolve a system that does not explode from the very wealth of choices that are now around us at every level.

Ad sense

Look at the ad at the top again – nothing in it surprises me, and I understand the motivation, but boy – that guy or girl is going to be one shiny unicorn, and I don’t know if there are very many prancing around with all those skills.

You know what, lets have fun: let’s see if I could get that job by a very scientific method of dissecting the ad and trying to match it with my blog posts. For this exercise we will be using a simplification that I actually possess in-depth knowledge about topics I write about (which is not a foregone conclusion, but let’s not go there):

As Magnus Pyke would yell – ‘Science!’. If this IBM thing does not work out, I should give them a call. My point was that there is a dire need for ‘making-sense-of-it-all-in-cheif’ in every large team. Again, this is too long, so we will call this job ‘full-stack architect’. If your company is large enough, there could be additional career ladder titles such as ‘Senior Technical Staff Member’, ‘Distinguished Engineer’, ‘Fellow’, but I really dig full-stack architect, so I will call myself that from now on.

Here is hoping that one day soon some future George Constanza will lie to people that he is ‘Art Vandelay, Full-Stack Architect’.

© Dejan Glozic, 2014