Today marks the one-year anniversary of me stepping into a formal architecture role from that of backend developer, so I've dusted off my old blog to reflect a bit on what I’ve learned so far.
You don’t have to be the best developer
Your value is not in the technical design
You can’t fix organizational issues with technology
Your political skills are more important than your technical skills
#APIs#APIAsAProduct#APIManagement#SoftwareDevelopment#APITesting#APIDesign#APIDocumentation: "I often make the point about API users that they fall into one of two buckets: the conceptual user (the dreamer) and the procedural user (the implementer). Breaking those two down is a blog post for another day, but essentially, this book is aimed at both, leaning more heavily toward the former.
Bruno embarked on his book-writing journey armed with a hefty dose of product thinking. He took the scenic route chatting it up with API aficionados, getting the lowdown of their challenges and triumphs. Turns out, we Product Managers are drowning daily in a sea of technical jargon without a life raft in sight.
If you’re anything like me back in the day, when I was a fresh-faced newbie diving headfirst into the API industry, you’ll relate. I’m talking fingers dancing across the keyboard like they were in some kind of turbocharged typing marathon during every single sit-down with architects, developers, and engineers. Seriously, the clickety clack of the keystrokes echoed as my own personal symphony: Reverie of Desperate Recall.
"This is another variation of the High-Tech Illusion: the belief that software developers do easily automated work. Their principal work is human communication to organize the user's expressions of needs into formal procedure. That work will be necessary no matter how we change the life cycle."
A weird thing about being 50 is that there are programming languages that I've used regularly for longer than some of the software developers I work with have been alive. I first wrote BASIC code in the 1980s. The first time I wrote an expression evaluator--a fairly standard programming puzzle or homework--was in 1990. I wrote it in Pascal for an undergraduate homework assignment. I first wrote perl in the early 1990s, when it was still perl 4.036 (5.38.2 now). I first wrote java in 1995-ish, when it was still java 1.0 (1.21 now). I first wrote scala, which I still use for most things today, in 2013-ish, when it was still scala 2.8 (3.4.0 now). At various times I've been "fluent" in 8086 assembly, BASIC, C, Pascal, perl, python, java, scala; and passable in LISP/Scheme, Prolog, old school Mathematica, (early days) Objective C, matlab/octave, and R. I've written a few lines of Fortran and more than a few lines of COBOL that I ran in a production system once. I could probably write a bit of Haskell if pressed but for some reason I really dislike its syntax so I've never been enthusiastic about learning it well. I've experimented with Clean, Flix, Curry, Unison, Factor, and Joy and learned bits and pieces of each of those. I'm trying to decide whether I should try learning Idris, Agda, and/or Lean. I'm pretty sure I'm forgetting a few languages. Bit of 6502 assembly long ago. Bit of Unix/Linux shell scripting languages (old enough to have lived and breathed tcsh before switching to bash; I use fish now mostly).
When I say passable: in graduate school I wrote a Prolog interpreter in java (including parsing source code or REPL input), within which I could run the classic examples like append or (very simple) symbolic differentiation/integration. As an undergraduate I wrote a Mathematica program to solve the word recognition problem for context-free formal languages. But I'd need some study time to be able to write these languages again.
I don't know what the hell prompted me to reminisce about programming languages. I hope it doesn't come off as a humblebrag but rather like old guy spinning yarns. I think I've been through so many because I'm never quite happy with any one of them and because I've had a varied career that started when I was pretty young.
I guess I'm also half hoping to find people on here who have similar interests so I'm going to riddle this post with hashtags:
@daverooneyca and I are doing a public AMA (ask-me-anything) on all things Agile on May 1 (next week). Bring your questions and get the perspective of two coaches who each have 25+ years of experience.
“duplication is far cheaper than the wrong abstraction”
— Sandi Metz in “All the little things” at RailsConf 2014
The quote is often put out of context to support the idea it’s always better to postpone the abstraction until there’s enough duplication. It’s used as an excuse to keep duplication for some arbitrary amount of time.
I was wondering if comments alongside source code are not read for reasons other than them being likely to be out of date. Maybe its because ... syntax highlighting makes them less readable?
Ooh, neat! PyCharm (and, I would imagine, other JetBrains IDEs) shows you all of the enclosing code you've scrolled past, to put what you're seeing into context.
The 20th BSDCan will include tutorials on PF, running your own email, TLS, BGP, and NSH, as well as two days of talks on everything from systems administration, networking, and programming.
The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.
About a month ago, I entered into a small "language contest" that was set to prove that no "newschool" language (Rust, Zig, Nim, etc) is ready to replace C in the embedded field.
The deadline was about 10 days ago, and according to the original technical evaluation criteria, my Free Pascal solution won, but got disqualified, because "we already know, Pascal could not replace C".
Programming languages rise and fall, human stupidity remains. I rest my case.