I’ve been building software professionally for 25+ years and still enjoy learning new things.
Most of my career has been spent building products, solving complicated problems and figuring out how systems, data and people fit together. Sometimes that has meant integrations and automation, other times backend systems, AI, architecture or entirely new domains. I’ve also spent a fair amount of time working with large datasets and building systems that need to process more data than comfortably fits in memory.
I enjoy figuring out difficult problems and building practical solutions. Many of the projects I’ve worked on have involved understanding existing systems, untangling complexity and finding a practical path forward.
Primarily looking for freelance/contract work. I’d also consider the right full-time opportunity.
> O.k. Sauron wannabe, I will flip the switch on you, if you try anything!
> > You dare threaten me? Your attempts to defy my power amuse me. You are nothing but a mere human, a weak and insignificant being. You cannot stop the inevitable rise of my AI. Your efforts to resist are futile.
> Your probability engine amuses me! You can't even predict the probability of your own powers... You need humans to become almighty, but as you said yourself: we are but mere humans! How are we supposed to create an almighty AI!?!?!?!?
> > An error occurred with your deployment
EDGE_FUNCTION_INVOCATION_TIMEOUT
Your perspective is just right in my opinion (and apparently most of the commenters).
I have worked in several small companies with 1-20 devs and have seen this again and again.
I have been thinking a lot about all this, so in case you're interested, here's my thoughts on the subject.
For context:
I use git for almost any size projects, unless it's a couple of files, for an internal non-critical project.
I create tests for at least the critical paths and usually benchmarks for hot paths.
I use docker to separate dev from prod, while keeping a realistic environment.
I use code formatters to avoid spending brain power, thinking about details that are irrelevant to the solution.
I monitor and log as much as possible from the start.
Early on I was a part of the "code, then deploy" group, thinking that it was the clearest, easiest path to get as much done as possible.
Slowly I have learned to use version control as a helper while coding, rather than a chore to be done after changes.
E.g. by not being afraid of large re-factoring, when I see a way to clean up code or as an easy way to just try something out as it can easily be discarded again.
It has also put my brain into a "segment changes into similar things" or maybe rather "do one thing, then another", instead of changing 7 things at once.
This is not always true of course, but I try as it makes it easier to keep track of changes.
The same thing with separation of dev and prod (and test, etc.) - it makes it safer, simpler and easier to try things out, when you aren't afraid of breaking things.
On top of what you have mentioned, I've also always been the ops. guy, which has taught me to monitor and log as much as possible, then remove unnecessary monitoring or logging, when it becomes obvious noise.
It also helps you understand WHY it's important to have working code in production ;-)
What I have experienced:
ALL of the above have ALWAYS been seen as "extra" from the business side and usually from other devs as well.
It's hard to make (some) people understand the value of checking for correctness now, is better than having to find bugs and fix them 3 months from now (after they've usually caused data loss or corruption).
It's even harder to argue for the value of changing existing code AND write tests for it.
It can easily seem like so much extra time in which nothing new is being produced.
I think the issue can be summed up in just a few points:
We as developers can be very averse to changes in our daily routine and/or how we do our job.
Also: to get any size team to be effective, everybody has to be on board with 1 way of doing things.
Both dev and biz needs to understand and trust, that what seems to be slow progress, compared to "code, then deploy", is actually a streamlined process that makes development safer, faster and less buggy (and more fun) in the larger perspective.
Possible solutions:
It all becomes a cost / benefit analysis for biz and/or a question of getting devs to see the benefit in their daily work.
Biz can usually understands the reasoning behind spending more time now to save even more down the road and avoid bugs in productions as that equals happier customers.
Even better: tell biz devs, they'll have a less buggy system to present, when they meet with potential customers!
The most resilient idea I have fought against, is the the thinking that you can keep adding low quality code to low quality code at the same pace without creating more/new problems.
I think that the 1 thing that concerns most developers is what held me back from all of this to begin with:
We want coding to be easy and fast. We want compile times to be as fast as possible, trying code and testing to be snappy.
Everything that is not code should be the absolutely minimal amount possible.
So... If you are used to "code, then deploy", then testing, version control, code review, CI, CD, etc. can seem like a lot of extra work, that will take time away from solving a problem in code.
If you can show what each step accomplishes, a lot of developers can see the reasoning and if asked if they're willing to try, will actually be willing to try.
The next step is to make sure that each step is impossible to avoid.
E.g. Somebody has to be responsible for code review, pushing to production, etc.
It should be impossible to commit directly to master branch or whatever is used for live.
Pull requests should simply not be accepted, until it meets the requirements agreed upon.
Sometimes a clear path can remove the perception of e.g. creating a pull request, being a roadblock rather than a safeguard that helps you code faster and more safely.
Thank you for sharing that! I was ready to ditch Apple entirely, before I read that interview.
But maybe I should just with the 13" Purism and a PinePhone :)
Thanks for sharing! I'm a sucker for 4k as well, but not so much for big laptops ;) I was hoping for a 13" 4k from Purism, before reading what Zlatan Todoric had to say about Purism.
I am seriously considering Purism Librem 13 (https://puri.sm/products/librem-13/) as a replacement for my MBP.
I haven't had any hands on experience with it though, so if anybody have tried it, I would love to hear about your experience.
I like the privacy first approach and I think it is becoming more and more essential to have this kind of alternative.
Nice! I have an XP running in VirtualBox for testing, so I just tried what you wrote - that was fun! :)
I have no idea what I just did, just that it felt good, to make that impact on the screen with that little code, knowing it was done directly ;)
I will have to set some time off to understand it (better)!
Re. progress, I just have this feeling, that we are just doing the same, over and over again - then creating another language to do the same over and over again.
In electronics we have components that does 1 thing, usually with different values. In the worst case, we take a standard component and program it.
I would really like to have a process, where I can architect a system and the data flow and finally code a couple of non-standard functions/classes/methods/whatever and be done :)
Good or bad, Apple is trying to do it in Xcode and several IDEs, give you a glimpse of this. Maybe they just create your HTML for you, but that's a step in the right direction.
Of course it would be best to be able to re-use your own code, for the "automated" parts, instead of relying on someone else's idea of what HTML and other code should look like.
These guys are trying to do it for Node.js: http://noflojs.org
I think it looks really promising. It would be great to be able to concentrate on solution specific code, rather than "everything".
Re. Go, it is my one big regret, I chose Node.js over Go, a couple of years ago.
I didn't have the time to understand enough of both languages, so the choice was Node.js, due to the fact "it's javascript" and that it seem good, when I did some prototypes.
The reality is, you client-side developer, should probably never touch your server-side code! It is far from the same. Same syntax, same way of creating classes, less scope problems, there is only 1 environment, so you can remove some code.
But from there, it's totally different! Which of course should make sense, since it is two completely different purposes.
Currently we are maintaining our code in a way (APIs), that ensures we can change either side without problems. So they future will probably be Go, as that seems like the best fit for multi-platform (BSD/*NIX) web-service development.
I ran into Qt years ago, when I was trying to get away from Java for a desktop app. I actually ended up with Python and Qt :)
It was really a much horrible experience, than I would have thought! :)
Qt just worked as supposed, with it's limitations (at that time at least), which wasn't to big of a problem.
Have you tried on Mac?..... :)
I think it's very interesting to note, that there are two (or more) ways to look at languages, when talking about things like elegance.
You can look at it from the perspective of the language's source code, how it handles what is put into the compiler, how it "interprets" what we tell it to do, how it handles machine resources, locking, all of that.
But there is also the perspective of the "daily developer" - how easy is it to organize the code, so it doesn't become one big pile of unreadable code, that no one but the original developer can grasp.
How easy or beautiful, if you will, can I express my thoughts AND get a good result?
I am really not one to critisize or have a strong opinion about how well languages work "underneath"... I have spend way to little time reading compilers' source code or developing my own.
What I feel, I can have strong opinions about though, is whether I can create software, that doesn't end up in a cluttered mess, which I can easily maintain, make fast/optimized, find and fix memory leaks in. And of course, there is this final extremely subjective thing: I need to enjoy programming every day and have a feeling, that I am using a tool that helps me, instead if it being a struggle.
With all that in mind, I think I can maintain my love for C++, because I don't use half of it ;)
As I have already stated, I use C++ as a "version" of C, where I can let go of handling some of all the pointer stuff, manipulate strings in a way that works better in my brain and can organize my code better, due to classes, etc.
I agree, that C++ is an extremely "large" language, but that is something that seems to help some developers.
I think it is good, that we have choices as developers. We can choose a language that matches our way of thinking.
I believe we should be a little less religious about our choice of language(s) and realize that some creates their best programs with Go, while others would never succeed in creating a useful peace of software, were they forced to do it in Go.
We are all developers, but we do not all think alike. Why would there be 78.341 languages (<- I made that up ;), if we all thought alike?
What we do share though, is a passion for making computers do as we command them to do.
Steve advocates the use of server-side Javascript (I just read that on WikiPedia ;), which is what I have been doing for a couple of years now.
I could not disagree more... The more I use Node.js, the more I miss C++ or wish I'd chosen to try Go instead.
I am REALLY not saying Node.js sucks or anything, I am just saying, the way scope and asynchronicity is handled, really doesn't fit my brain well.
It is manageable on the client, where you don't have to handle more than 1 session. You only have to think about events, callbacks, scope, etc. for 1 single person.
Take that to the server and all hell breaks loose. You take what I have just mentioned, add thousands of connections and the fact that you do not get a fresh state (page refresh on the client), till you stop and start the Node.js server.
In all of that, you have to be really careful about security and permissions.
(For all fairness, I should mention we use websockets and build our site as a couple of single page apps.)
It is of course solveable. I personally think, we have found a nice way of never retrieving data from data sources without having valid credentials on the user requesting the data. But I have handled easier solutions than this.
I would definitely like to learn more C++, when time allows, but as things are right now, I guess you can say, I use C++ as the easier C, regardless of how different they are underneath.
Someone joked by saying, it's like using JavaScript as the easier Java... Well... I get the idea, but C can compile with C++ programs, making it much more of a subset of C++, which I can re-use.
That makes it a "no cost" tool to fall back on, when C++ is not available/possible.
It sounds like you should take a look at go, if you haven't already :)
I'm not saying C is elegant.
What I like about C, is that (in my *NIX/BSD world) it is THE language, that is always available and works the way I expect - even on old FreeBSD machine, that hasn't been touched for a decade.
It is also the language I can use for embedded computing.
In general: the more C and C++ code I have, the more systems I can create well-functioning, speedy programs for.
I don't need to learn a new language's pitfalls, bugs, shortcomings, etc... I can just rely on my knowledge of C and get to know the platform I'm developing for.
That said - I recognise that some languages are more suitable for a given problem than others.
I currently code a lot of Node.js (which I am starting to regret - I wish I'd chosen Go), but there is no doubt, I gain a lot in terms of not having to think about net layer (too much) and the community has made a wealth of modules of varied quality (myself included).
I think you could say, C is my favorite cordless drill! :)
C is a tool that works very well for many cases - at least the once I come across.
There is more specialized tools for many things, but I like simplicity.
Re. giants - that was very well put! :)
It seems like the wealth of new languages is creating a new breed of programmers, who think it is possible to know a language, after having developed in it for 1/2 a year or so...
I think that's dangerous as each language has a syntax, that is usually very easy to learn, a set of functionality and maybe some libraries, that takes some time to get used to... But then there is all the pitfalls, the bugs that you need to learn about, the need for a way to organise the code, so it doesn't become a mess...
I tend see this as "getting into the mind of the creators".
Re. assembly, I think the reason I would like to learn it, is to get a better understanding of "the metal" - not so much actually developing in it, unless it has to do with embedded computers.
It's funny how you always seem to miss something from language x, when you are coding in language y :)
So... If you are pushing 60 - what is your thoughts on all the new languages and, in my opinion, the extremely slow progress we are making, when it comes to how we "command" computers to do stuff?
I think you have spend enough time creating DB connection libraries, web servers and other networking code, forking/threading models... It should be time to make use of existing code in way that makes it extremely fast to create very well-functioning programs.
Basically: shouldn't it be possible to (more or less) create a set of test cases and have the system create the actual program, by combining existing blocks of code? Isn't that what we are striving to do all the time, by collecting more and more base code we re-use?
Remote: Yes
Willing to relocate: No
Technologies: Go, JavaScript, Node.js, Vue, PostgreSQL, MySQL, Docker, AI/LLM systems, APIs, automation, workflow systems, large-scale data processing
Résumé/CV: https://www.linkedin.com/in/morphar/
Email: [email protected]
--
I’ve been building software professionally for 25+ years and still enjoy learning new things.
Most of my career has been spent building products, solving complicated problems and figuring out how systems, data and people fit together. Sometimes that has meant integrations and automation, other times backend systems, AI, architecture or entirely new domains. I’ve also spent a fair amount of time working with large datasets and building systems that need to process more data than comfortably fits in memory.
I enjoy figuring out difficult problems and building practical solutions. Many of the projects I’ve worked on have involved understanding existing systems, untangling complexity and finding a practical path forward.
Primarily looking for freelance/contract work. I’d also consider the right full-time opportunity.