A decade in the industry; a ten year retrospective
-
Recently, a milestone had passed me by without my knowing – the original start date for my very first programming job was May 3rd, 2010. Ten years have flown by (or in some cases, have dragged by), and much has changed both in my personal and professional life, and much has stayed the same. I thought it would be a nice exercise to look back and see where I came from.
Click here to see the full blog post
-
I would never have imagined that I would've made the jump to entrepreneurship, the antithesis of a steady paycheque!
Congrats.
The best of life is living by interests and you make it. Previously I was an assistance prof in an university. Then I quit since I dont like it and I am trying to live by my interest.
-
@gotwf @julian I have a similar line in the industry, but in fact, over a longer period - 30 years+ to be precise. It's documented here - https://sudonix.com/journey
-
@phenomlab yeah, mon! I realize ye' be old n' gray but ten decades is one hundred years. Hence I imagine even the old farts among us have a ways to go yet fer' that one, eh?
Rock on!
-
@phenomlab Meh... more like Much ado about nothing.....
Unless you were being purposefully clueless....
-
@julian One may hope not. Leastwise.... what is special about those dates? I know not. Mayhaps were you referencing the 2038 Unix Epochalypse? I think this has potential to be far more problematic. I have been aware of this since the great Y2K "crisis" but kind of forgot about it until this thread since 2038 was a "long ways off yet". I also thought this would be no big deal in future modern times due to the prevalence of 64 bit processors and os platforms. Alas, I seem to be in error:
There is no universal solution for the Year 2038 problem. For example, in the C language, any change to the definition of the time_t data type would result in code-compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to 2106 (specifically, 06:28:15 UTC on Sunday, 7 February 2106), would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. Increasing the size of the time_t type to 64 bits in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions. [emphasis added]
Could be in for some interesting times, eh?
-
J julian moved this topic from Announcements on
