keeeeeeeem
Here are some things I think are helpful for long term growth (YMMV):
- "The Mythical Man Month" by Fred Brooks is a classic for a reason.
- Learn how your tooling works to a reasonable level. It's worth investing time into tooling as you use it every day.
- For your long term technical development dabble with other languages and libraries, try to understand why and how they do things differently.
- Ignore orthodoxy, but educate yourself on why developers follow it and come to your own conclusions as to whether you agree or not. This means reading widely but sceptically, check out many different open source projects.
- A lot of what constitutes current industry best practice is not written for any one developer/organisation and the chances are it won't apply to you. There are organisations of all sizes dealing with problems of all different types and the current language/framework/library/infrastructure pattern of the month may or may not have been developed with you and your organisation in mind. Don't be taken in just because everyone's talking about it.
- Set aside object orientation and type systems for a moment and learn the language of data. Data structures and operations on them, normalisation & the relational model and how to model a problem domain as data are all more important than class diagrams or arguing about whether composition is better than inheritance. Once you understand and can navigate how data works, you can apply those rules to any programming paradigm you want.
- You need to know how to operationalise your projects, or at least communicate effectively with people that do. Writing code and throwing it over a fence to QA or ops won't do.
- If you're building code that will be exposed to the internet, you need to understand application security. Check out OWASP.
- If you're not working in organisations where coding standards are cared about, consider moving on. On the other hand, beware holding too strong an opinion. If your tech lead doesn't follow Martin Fowler's, or Bob Martin's, or the GoF, or test-driven development, or whoever else you care to name, that doesn't mean they're "doing it wrong". Nearly all "rules" and "laws" in programming are just some person's opinion.
If anyone reading this is interested in compile-time computation, you owe it to yourself to read Paul Graham (of HN)'s own work on compile time programming, "On Lisp"[0], or to take compile-time ideas to the next level, Doug Hoyte's "Let Over Lambda"[1] (LOL). Lisp languages have a long and interesting history of compile-time computation via their various macro systems, and given the first-class inclusion in most Lisps, a greater variety of ideas have been explored regarding compile-time computation.
A few interesting examples:
LOL's "Pandoric macro"[2] lets you monkey-patch closure values. It's absolutely bonkers and would almost certainly be pathological to introduce to a codebase, but it's an example of pushing the boundaries of what's possible.
Common Lisp's object system, implemented via macro[3]. To be honest, the entire Common Lisp language is a masterclass when it comes to learning about macros (I can't avoid mentioning Scheme's hygeinic macro system and Lisp-1/Lisp-2.)
A special non-Lisp shout-out goes to Rust's Diesel library for embedding SQL DDL queries into macros[4] which is not something I've personally seen before.
Clojure has a few interesting (and practical) macro libs, particularly core.async, which is an implementation of CSP (similar to Golang's channels AFAIK), it embeds perfectly into the existing language and extends its capabilities even though it's merely a library. Another interesting lib which comes to mind is Meander[5], which uses term-rewriting to provide transparent data transformations. Think declaratively interacting with data structures at compile time, and the library figuring out the best way of turning it into imperative value manipulation code.
[0] http://www.paulgraham.com/onlisp.html [1] https://letoverlambda.com/ [2] https://letoverlambda.com/index.cl/guest/chap6.html#sec_7 [3] https://mitpress.mit.edu/9780262610742/the-art-of-the-metaob... [4] https://diesel.rs/ [5] https://github.com/noprompt/meander
As I understand it they have released some of their mobile dev REPL tooling under an open-source license (Krell).
Good luck!
You say you're good at managing and strategy but have founded five businesses that are at best treading water. Are you perhaps "teaching the birds to fly" and should return to the basics in order to speak from authority? Find a technical co-founder and bootstrap a business focusing on growth and profit metrics?
Topre switches, on the other hand, have been worth every penny.
I'm somewhat glad I made it out the other side; as a babe in arms programmer I was fully taken in by these ideas. It's a great game of fun creating these overly complex, but ultimately arbitrary, sets of rules. They serve no real purpose other than creating and solving mental puzzles. There's a reason Software Architects don't (shouldn't) exist any more.
Other topics that come to mind are books about building out microservice architectures. There are certainly plenty of war stories out there and micro-services seem to tend towards re-implementing OTP runtime primitives in arbitrary languages as design patterns, so you get even more of a feel for what's going on at a lower level of abstraction.
Previously I had worked for a startup in the finance space and had increasingly been more involved in the security aspects of our development process. I was impelled to make the jump to security because I wanted to dive deep into the topic and I knew I wouldn't get the depth of knowledge from my SWE job.
The majority of people in security I come across have a surface level knowledge of many topics and depth in perhaps one topic, which will give you an advantage in your previous domain (i.e. web applications).
In my country, the pay for pentesters is lower than for developers by 10-15%. In my experience day rates for testers ranges from 800-1400 EUR.