You need to learn how to communicate with other developers and understand their ideas and arguments. Same goes for customers, and management. Therefore my suggestion is to invest time in building up a good working vocabulary of technical and organisational skills. Take the time to mentor others even on small things, it forces clarity of thought and being able to speak about a topic. I have known absolutely amazing developers who can't talk or explain their decision making process, and it handycaps them since they can't expand their skillset past churning out code. As someone who has changed fields a few times, rebuilding my vocational vocabulary has always been the most time consuming and difficult part.
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.
I can't speak to the quality of Zig's compile-time compilation, other than to comment and say the article is taking liberties with its use of the word unique. As other commenter's have noted, many languages have the feature. Instead I'm going to talk about a bunch of cool and weird compile-time code implemented by people much smarter than I.
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.
David Nolen gave a relevant talk[0] about the workflow they use to integrate Clojure and React Native for mobile and web development at the company vouch.io. You say "I'd like to reuse the frontend part of the web app", their methodology involves using Storybook.js to ensure their React components are truly stateless and may be re-used across environments.
As I understand it they have released some of their mobile dev REPL tooling under an open-source license (Krell).
Nobody can answer what you should do because you haven't mentioned what motivates you.
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?
I can't speak to finding part-time gigs but outside the US, it is common for contractors to earn multiples in the order of 2-4x the equivalent employee salary. Monetarily, it's almost always worth it to make the jump to contracting if you have the ability and choice to.
My experience with MX switches was that they were terribly underwhelming, they felt cheap and in the case of MX browns they somehow made my keyboard accuracy decrease.
Topre switches, on the other hand, have been worth every penny.
I fully agree. If I see those names attached to a project I take it with an extremely healthy dose of scepticism (and usually run the other direction).
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.
It's not exactly what you're asking for but if you want to grok distributed systems and managing workloads then learning some Erlang/Elixir (OTP runtime) really helped me, as you can "code along" with your book of choice and they handle real-world situations like node failure and backpressure management.
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.
I've got 5 years as a full-stack Vue.js/.NET Core/AWS developer and 2 years as penetration tester. I didn't know we were this rare, but it's nice to hear.
Client-side databases are relatively popular in ClojureScript land. DataScript and Fulcro both come to mind immediately. DataScript is an immutable in-memory database that uses Datalog to describe queries and Fulcro is a full-stack framework that automatically normalises your database.
You're missing nothing. Class based OOP is essentially a set of arbitrary ontologies forced upon you by library authors. Your interpretation is no more or less meaningful than the others.
While London and Londoners are very friendly, I would recommend considering secondary cities in the UK as a destination, for example Manchester, Bristol, Edinburgh or Cambridge. The pay is usually comparable to all but the highest London rates and the cost of living is lower. They also tend to have very active music and art scenes and are slightly less tainted by the sheer amount of money sloshing around London. If there's an internationally known university and a reasonably sized city centre you won't go far wrong. A word of warning, some ancient and well renowned universities are situated near otherwise quiet cities, which have a charm of their own, but some research will be required.
I moved from fullstack development to pen testing. I don't have any certs, but I'm working towards one purely because clients prefer it.
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.
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.