> 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.
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.
Not sure I can take him too serious. I have now 3 laptops from purism (2 old 13” and one 15” ). they are great.
He’s mostly talking about the phone project (which is hard).
Don’t know about Purism, yet have friends who worked with/on Jolla and his comments sound too harsh. PinePhone is interesting, yet haven’t seen much and I doubt they will be doing better ... Jolla shipped (yes with some proprietary blobs ), but was a great product (loved their work also before on the Nokia n110 ... my first mobile internet device).
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 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.
Actually, I love C and think it is very elegant=P, especially when you read its source code. But my favorite languages are Common Lisp, Ruby and Haskell. Concerning C++, I have to agree with most part of what Steve Yegge said http://bit.ly/1dUsZsv, although I used it on a daily basis... The only reason I am doing it is because the legacy code of the system is written in C++.
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.
> > 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