The struggle to stay up to date is real...

We all know the software development industry is a non stop innovation avalanche
barreling down a mountain.

So staying up to date with all the tech you touch is becoming a real struggle. When I started out as a developer many years back, I felt staying on the bleeding edge wasn't too bad.
I mean I needed to know and keep in touch with:

• My main language and some of its main frameworks..  Java / Junit / Hibernate   
• Some html, javascript, applets, JSP tags
• Some RDBMS and SQL.. Latest changes on Oracle / SQL Server, how their indexing strategies change between versions etc.

These days however the list of technologies, frameworks, languages and tools has just exploded.

I have in some way or other worked with, tried, read about, implemented, studied, interested in or affected by the following in the last year. Most of which have shipped so much functionality it's actually mind boggling :

• Java
• Java 7 to 8 
• Frameworks: Spring, Spring Cloud, Spring Boot, Hibernate 
• JavaScript
• TypeScript
• Go
• Python
• Testing:
• JUnit, Cucumber, Pact.IO, Selenium, Jasmine, Karma, Protractor, Hamcrest, Shazamcrest, Mockito
• AngularJS
• Angular 2 / 4
• Docker
• Docker, Compose, Swarm
• AWS
• Lambda, DynamoDB, Step Functions, S3, Cognito, ECS, EC2, VPC, Cloud Formation
• Netflix
• Elastic Search
• LogStash, Kibana
• Weblogic
• Tomcat
• Kubernetes
• Kafka
• Pivotal Cloud Foundry
• Caching
• Hazelcast, Redis, EHCache
• Storage
• Oracle, MongoDB, Prometheus.io, Neo4J, H2, MySQL, InfluxDB
• Build + CI/CD
• Jenkins, Bamboo, Concourse
• Git
• Windows Server, MacOS, Linux, iOS
• Blockchain

I am pretty sure there are a couple others that I am missing... and not mentioning the architectural styles, patterns, agile practices and the like so prevalent in our industry.

What sparked this blog post was watching the DockerCon Videos from May...
I would say I use Docker pretty regularly, generally on quite simple use cases for my own development and some work related projects...
But watching the videos below I realized that I had completely missed out on a ton of new functionality I didn't know about...

The reason I could watch a DockerCon video 11AM on a Wednesday morning is because I am current between countries and therefore between jobs... So I have a week or 2 to kill, and obviously I jump at the opportunity to go check out some of the latest stuff...

However seeing how many changes there were and that I missed a lot of it...
I think I may need to schedule "tech-cations" every couple months to just gorge on all that is new for a couple days.. or hopefully with the use of public transport in my new city, I can cram in another hour or so of podcasts or videos into my daily schedule.

TOGAF 9.1 Notes

I was considering doing the TOGAF 9.1 certification. I have gone over all the content, to at least have a decent idea, what TOGAF is and what it is trying to achieve.
However based on my current position, interests and trends I decided to rather focus my attention elsewhere for the moment.

So just to note down all the resources I found, used and other relevant resources links incase I do have the time or the need to come back to it.

Training course UDEMY (Scott Duffy):
https://www.udemy.com/togaf-enterprise-architect/
https://www.udemy.com/togaf-part2/
I would avoid the Exam Strategy one (https://www.udemy.com/study-togaf) as I found it a little bit of a waste, and he covers a lot of the content in the other 2 courses anyways.

Books / PDFs:
The Actual TOGAF specification (PDF)
TOGAF 9 Foundation Exam Study Guide
TOGAF 9.1 Quick Start Guide for Enterprise Architects (Not sure where I got a PDF from)
TOGAF Cheat Sheet from Scott Duffy's Udemy course.

Other Useful Resources:

http://theopenarch.com/

https://setandbma.wordpress.com/2011/03/31/togaf-foundation-level-certification-another-practice-test/

http://www.bestpracticehelp.com/togafquiz.html

http://class10e.com/TOGAF9/

https://chriseaton.wordpress.com/2009/08/24/togaf-9-certification-multiple-choice-questions/

http://hexopus.com/togaf-study-guide/togaf-9-foundation-quiz/

http://class10e.com/TOGAF9/based-on-togaf-9-which-of-the-following-is-the-best-answer-is-this-the-right-answers-to-choose/

The Pragmatic Programmer - Review / Summary Notes.

I recently finished The Pragmatic Programmer, to be completely honest this had been the 3rd attempt to read it, although the book is good and well worth the read, I had unfortunetly learnt most of the lessons the hard way on my own over the last decade or so of being a software developer, so I found often myself easily distracted.

I have to add, had I read this when it was published it would have undoubtedly saved me some pain, but even with that it's always good to reaffirm some of your good habits, and keep your bad ones in check. It covers 46 sections with 70 different tips that are generally useful to any programmer. Jeff Atwood - coding horror made a list of all 70 tips.

As with most things some tips are "more equal" than others, the ones that really stick out and probably can't be emphasized enough are:

  Care About Your Craft
Why spend your life developing software unless you care about doing it well?
  Think! About Your Work
Turn off the autopilot and take control. Constantly critique and appraise your work.
  Don't Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
  Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
  DRY - Don't Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
  Make It Easy to Reuse
If it's easy to reuse, people will. Create an environment that supports reuse.
  Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
  Don't Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.
  "select" Isn't Broken.
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
  Design with Contracts
Use contracts to document and verify that code does no more and no less than it claims to do.
  Crash Early
A dead program normally does a lot less damage than a crippled one.
  Minimize Coupling Between Modules
Avoid coupling by writing "shy" code and applying the Law of Demeter.
  Don't Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don't confuse a happy coincidence with a purposeful plan.
  Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
  Design to Test
Start thinking about testing before you write a line of code.
  Some Things Are Better Done than Described
Don't fall into the specification spiral at some point you need to start coding.
  Don't Be a Slave to Formal Methods.
Don't blindly adopt any technique without putting it into the context of your development practices and capabilities.
  Don't Use Manual Procedures
A shell script or batch file will execute the same instructions, in the same order, time after time.
  Test Early. Test Often. Test Automatically
Tests that run with every build are much more effective than test plans that sit on a shelf.
  Coding Ain't Done 'Til All the Tests Run
'Nuff said.
  Test State Coverage, Not Code Coverage
Identify and test significant program states. Just testing lines of code isn't enough.
  Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

Surviving the Wild West Development Process

Now in a perfect world, we all strive for a some kind of development process, be that: Waterfall development, Prototyping, all things Agile or whatever process the CIO / CTO /CEO got sold on by some consultancy.

But in the real world what sometimes ("sometimes" being quite often actually) happens is:
What I like to call the Wild West Development Process (WWDP)... the main principle is basically “promise first and ask questions later”.

Getting started with WWDP is pretty simple:
1. You need someone, somewhere in a place of power and influence in your organization to promise software by some unachievable date.
2. Add in a eager marketing department and some press releases…
3. stir and leave to simmer.
4. After simmering for a while inform the software development department that they must have something, that does "stuff" and the release date can not change.

I am not sure if this is a result of a immature IT industry in my country, but I have spent many years in environments like this. It even seems to find me in the most unlikely employers, the large corporate organizations like insurance and banking institutions, where general red tape and corporate processes should limit this. I started my career in one of those “startup-sell-information-tech-and-business-processes-to-anyone-cheaper-than -anyone-else-type-consultancies". Which means every project was driven by WWDP so I started in the deep end, and for about 4 years I knew no other way of developing software. I currently find myself in another one of those projects. I'd like to share some points that I found helpful in actually delivering some software in unimaginable unmovable deadlines.
(to be fair some of these are in the standard development processes mentioned earlier, maybe with just different priorities)

Pick the right developers
Not everyone can cope in this environment, knowing your staff / team is very important: late nights, constant crisis, constant changes and bucket loads of pressure and stress aren't for everyone. Some people thrive, some survive and run for the hills after, some just end up whimpering in the corner and need to be replaced (which is a disaster).

Have the developers involved.
Projects like these don't allow for the usual requirements / design / develop / test paradigm, all of these functions run concurrently. Having the developers know as much detail as the architect, analysts and testers is vital. Developers will have to make decisions affecting the architecture and business functionality constantly, if everyone has the same picture you'll save time.

"Prototype" early
I say "Prototype" in quotes because unlike an actual prototype there won't be time to throw this code away. This "prototype" is to have the system in it's entirety up and running very early in the project. It can be a "shell" but having it up means testing can start early even if it's just the basics and no business functionality. Since there are no real requirements, make sure the design caters for adding them as they are defined.

Integrate early
If the system has any integration points, between systems, teams or external parties, make sure this is also in the "Prototype Shell", integration always takes longer than you think, having the interfaces up and available to test is crucial.

Keep track of communication
When the shock of not meeting an unachievable deadline kicks in, someone will always look for a scapegoat, always keep at least an email trail making sure you aren't that goat.

Automated builds and deploys
The standard agile practice of continuous integration is as important as ever, and even if you skip other parts of you software development cycle this is something that should not be dismissed.

Focus
With hundreds of things that need to happen a matter of days or weeks, it's very easy to try do 6 things at a time. Don't. Micro manage your time and tasks and focus. It's easy for us developers to start a task, see something, change something and lose a day which you don't have in the first place. If you have to, have someone keep an extensive list of "TODOs" that can be used in the cleanup phase.

Clean up
Once the unachievable deadline has been met, before starting the next phase, have at least one "cleanup" release. This cleanup phase should add very little or preferably no new functionality, but will allow for design and development decisions made in haste to be reviewed and refactored.

Pace Yourself
No matter how super human you may think you are, all of us have a limit to how many hours we can keep going. At some point you are actually being counter productive and a couple more hours sleep will actually help the project a lot more.
Know your limits.

I am sure there are a couple more, but currently being on a WWDP project I need to re-focus and leave that for the clean up phase later :)