by jamghee on 12/30/23, 3:51 PM with 299 comments
by dexwiz on 12/30/23, 11:02 PM
Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool.
Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Wiring up a form shouldn’t take html, js, and a serverside language.
On the flip side, don’t put your core business logic in low code. Low code builders assume anything complex will be offloaded to a specialized system. The best ones provide escape hatches by calling remote APIs or calling a code module.
Low code gets sold to smaller customers because it’s touted as a developer replacement. But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It’s easy to get them to configure something in a SaaS they already use, than get a custom solution from IT. Also low code often comes with guardrails and permission sets tied to existing users.
I see low code as a tech equivalent of the last mile problem in logistics. It addresses a large number of concerns with simple tools, but doesn’t scale well and needs to work in tandem with a stronger central system. End to end low code is a trap, but low code at the fringes is a multiplier.
by siliconc0w on 12/30/23, 11:06 PM
* there is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control.
* the workflows are poorly if at all documented.
* they still require a lot of custom code but that code isn't as reusable, tested or testable * they often require a proprietary runtime, worse this may only run on windows
* they are difficult/impossible to instrument and so are difficult or impossible to monitor. Or if they do have monitoring it is going to work differently than the rest of your stack - likely using email based alerting which isn't ideal.
* the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
The only tool that was semi-reasonable here was Looker which isn't exactly marketed as low code but at least in the version of the product I used did integrate with source control. Though generally the people writing lookml were still engineers.
I'm much more a fan of composable platforms that compress complexity but still make it possible to delve, customize and extend when necessary.
by anyonecancode on 12/31/23, 12:37 AM
Layers of abstraction are powerful when they're tight and well-suited to their purpose (I'm happy to never think about memory allocation -- thank you garbage collected languages!), but when leaky or ill-suited can be very frustrating and make things harder or impossible.
It's hard -- probably impossible actually -- to build a "general purpose" abstraction layer that will work for specific purposes, but that's essentially the pitch of low code -- we don't know your specific use case, but we have a tool that will abstract away all the code previously tailored to that use case.
Now, in fairness, there's a lot of code that has too much accidental complexity in it. A good abstraction layer strips away that accidental complexity and leaves only the essential complexity that's specific to your domain and use case. But that's hard to achieve -- it takes skill and experience (and not just general experience, but specific to your domain experience) to achieve. Most companies don't have that available to them, and don't want to pay rates to build teams that do have that skill set and experience. Low code holds out the promise of being a short cut to that, but clearly if your own dev team can't manage it, the odds of a generic platform doing it for you is slim to none.
by netman21 on 12/31/23, 12:45 AM
by MetaWhirledPeas on 12/31/23, 4:23 AM
In general I see little value in any large system intending to reduce the amount of code or the needed skills of the developer. Code is not costing you money. Good developers are not costing you money. You know what costs money? Bad developers making bad decisions using bad tools, necessitating years if not decades of paying armies of lesser-skilled developers to maintain the mess, slowing overall progress to a glacial pace.
by ctrlp on 12/31/23, 2:33 AM
Startup can't afford more than one developer? Product owner can hack the thing until you get customers, funding, or go out of business. Oh, and that bus factor goes up to boot. No more pager duty.
Code things that are core to your business and plan for the TCO. Use low-code for internal business apps and let your smart intern or low-code consultant make and own it.
by cgrealy on 12/30/23, 11:01 PM
If you want to build a shed, go to your local hardware store and buy a kit set.
If you want to build a skyscraper, get an architect, some engineers and a competent building company.
by tmn007 on 12/31/23, 12:06 AM
The "IT" dept had to spend a fortune re-validating the user requirements for the various applications, documenting and then converting them into a new platform. Obviously a lot of feature creep and previously accepted bugs (no longer accepted now that responsibility was no longer theirs).
A lot of the applications were frankenstein efforts from people over the years - lots of dead code no longer used, no docs etc. As others have mentioned people create mission critical stuff for their project or team, and then leave or be away on extended leave and it breaks etc.
by ubertaco on 12/31/23, 2:18 AM
I find that generally the answer is most often "no," which is kinda a nail in the coffin for serious usage of "low-code."
by bruce511 on 12/31/23, 5:07 AM
Of course, just like say the SQL or NoSQL debate there are contexts where one wins, and another fails.
I did have to smile at this though;
>> "Now, rather than being to recruit from a large pool of ubiquitous, open-source language developers, the company has to find maintainers who are very specialized in this tool."
From a company point of view this is correct. You cant just discard programmers and get a cheap, out-sourced one as a replacement.
On the other hand, as a somewhat older programmer, I like the idea that I get more valuable with age not less. I like that I can't be replaced by some ubiquitous open source freelancer who works for $20 an hour.
For the record I've been working with a low-code tool for 30 years (since long before "low code" was even a description) and I've seen thousands of one-man companies be successful developing programs where the owners actual programming skills are, well, in most cases, somewhat poor.
Turns out, making something useful has more to do with fixing pain, and less to do either writing code.
And yes, all the points listed in the article, and these comments, are true. And ironically almost none of it actually matters.
There are a million reasons it -shouldn't- work and yet, somehow, at least in my world it does.
by doubloon on 12/31/23, 3:36 AM
VBA (Visual Basic available in Excel and Outlook) had a lot of the same issues as low code, as in no version control, no workflow for review or continuous testing and integration, no ability to do lots of custom things, that did not stop it from running the planet. I mean if you did the VBA version of Thanos-snapping half of all VBA code out of existence, most of society would cease to function within a week.
Power Automate is going to replace VBA soon because VBA can no longer talk to web pages thanks to the end of Internet Explorer and lack of VBA updates. And like VBA, Power Automate has all of the same problems - no concept of code review, version control, history, logging, actually its worse.
VBA at least let you have custom Types and Classes but in Power Automate everything, literally everything, is a global variable. Power Automate is lower code than VBA. But I think it will be used even more.
Because it is already installed on every almost every office computer in the world. This is the only tool ordinary Ops people will have available to them to automate stuff, so that is what will get used.
by phamilton4 on 12/31/23, 12:39 AM
Then I found out the developers assigned to working on the low/no code parts had a component where they could write Java inside their low code process. There were hundreds of lines of code in each business process in the low code parts. They were writing giant methods in their process wired up by the true low/no code part.
To make matters worse the tool did not support unit testing of the custom code.
It ended up being like dozer mapping entity to entity and then passed along to custom code. All wrapped in some crummy UI. It produced a jar file which would be deployed anyways.
Maybe the tools are better now. We had some Tibco product at the time.
by bazil376 on 12/30/23, 4:02 PM
by Eji1700 on 12/31/23, 12:10 AM
It is so so so close to being a silver bullet tool for quick front end crud that can use your AD to authenticate.
Instead though, it’s got the most absurd pricing model that even their own reps don’t understand and is missing critical or basic features, requiring strange workarounds (fucking UTC dates vs what’s actually in the DB).
They USED to have no way to reuse code as well but they fixed that.
I feel like the issue is they’re still too married to basically low/no code environments.
Having a “I’m going to need to do a custom script in whatever” option would smooth out the edges so much
by debarshri on 12/30/23, 11:00 PM
Eventually we moved to nextjs and vercel. We are faster with iterating on our landing page as well as any engineer can be pulled into the implementation.
All lowcode platforms are great in basic usecases but fails when the usecases because complex.
by fnordpiglet on 12/30/23, 11:07 PM
by simonw on 12/30/23, 11:47 PM
by appplication on 12/31/23, 2:32 AM
In the end, you end up with either less skilled people getting in too deep, or highly skilled people unable to fully avail their skills. I get the appeal, but it always seemed like a local optima to me. It turns out code is a pretty good interface.
by GabeIsko on 1/1/24, 8:43 AM
Everyone is happy! Especially the people who actually have to use the software made this way! As we all know, enterprise software has a reputation for being extremely user friendly...
by msla on 12/31/23, 1:07 AM
Talend is an ETL tool: Extract data from a data source (file, database, API), Transform it, and Load it into another data source (file, database, API), all in a pipeline. Talend's happy path is the same as Unix shell's happy path: A pipeline of data with no side-effects and no globals. Try to deviate from that and you hit walls, some more climbable than others.
For example, Talend absolutely will not allow you to re-combine a pipeline you've split; you can combine two separate data sources, and you can split to two separate sinks, but you absolutely cannot go from one pipeline to two pipelines back down to one.
The saving grace is that Talend is fundamentally a GUI for writing Java. You can see the Java it's writing, and you can add your own Java in a few ways, from adding jar files to just plopping a pipeline component that allows you to insert your own Java into the big God Method that the rest of your pipeline helping to form. Be sure you know how scoping works if you do that.
In extremis, you can "use Talend" in that you use the Talend GUI as an Eclipse IDE to write the one pipeline component that does everything because it contains all of the useful Java code. You can use it the way I often used it, to take care of some tedious "plumbing" code to route the pieces of data created by the hand-written component to their respective outputs, including handling some minor output conditioning that can be done in a stateless fashion. It can even be used as it was intended to be used, as odd as that sounds.
by ralusek on 12/30/23, 10:58 PM
by codeptualize on 12/31/23, 8:45 AM
These tools can be useful for non devs to make very basic things, but they won’t be able to handle anything complex, and it’s hard to test and proof the correctness of the result. If you take it far enough you are always going to end up hacking around the tool.
For people who do write code these tools could be useful, but code is much easier to use as you are not stuck within the constraints of the tool and know what you are doing.
I think there is one success story for low code and its basic websites, mostly the part where a design is turned into code. I use Framer because it’s objectively quicker than code, with great results (I even design in framer), and once it’s set up non technical colleagues can make changes. Great for a landing page, but it won’t work for apps.
I think the article is right in pinpointing the logic as the problem. Coding is not about syntax and the language, it’s about the logic and ability to map that out into a program with all the edge cases and details.
by icedchai on 12/30/23, 11:32 PM
by atoav on 1/1/24, 3:15 PM
Low code is a dumb persons idea how to make programming easier — the kind that thinks memorizing all the weird letters and signs is what makes programming hard. The result will be that you will have non-programmers learn how to become programmers by failure — in production — on the job.
I always welcome things that bring complex system interactions closer to learners. But it comes with considerable risk : )
by kkfx on 12/30/23, 10:58 PM
The rest is the nth failed tentative to makes users jailed by ignorance selling the idea people can do thing without knowing things. It will fail like any other tentative done before.
by ivix on 12/31/23, 5:50 PM
Low/no code solutions exist for when there isn't enough time or budget for a developer created solution, which is to say, pretty much all always. In the real world of business problems, almost nobody has access to a professional developer.
by pylua on 12/31/23, 2:23 AM
The main point is it has its place — and choosing when and where to use it is critical.
by rikroots on 12/31/23, 11:22 AM
A few years go by. Someone in Big Important Company decides the courses need updating. Work ends on my desk as my bosses have the contract to maintain various other bits of BIC's creaking self-hosted intranet. I ask questions like "What software did BIC use to develop the courses?", and "can we charge BIC the cost of getting the software so I can do the work?" Of course, the answers are all along the lines of: no.
So all I have to work with is an extensive set of hefty change requirements to the courses, and a SCORM package downloaded from BIC's intranet. A huge amount of learning (how to manually edit SCORM packages) and frustration (how to test changes to SCORM packages), and a few months of time when I could've been doing something better without deadlines harassment ... I completed the work. Which I wasn't allowed to test on BIC's intranet servers for "security". So I just uploaded the new SCORM package to their production servers and went on 2 weeks leave.
by nextworddev on 12/31/23, 12:25 AM
But not the conventional low code platforms like web flow or retool or power apps.
It will be AI native and built in a visual+conversational manner.
by bombcar on 12/31/23, 1:10 AM
by jayd16 on 12/31/23, 4:49 AM
by shermantanktop on 12/31/23, 1:18 AM
Which I can understand, because engineers are expensive and behave in ways that are unintuitive for non-tech people.
But I fear “generative AI coding tools” appeals to the same people for the same reasons, leading to the same results.
by bazoom42 on 12/31/23, 1:11 PM
Much discussion around low-code (and no-code) miss that it is just abstraction. The question is not if we should use abstractions or not, but what constiutes good and bad abstractions.
by somat on 12/31/23, 2:31 AM
The only 4gl I know of that held the test of time was SQL. Every other one ended up being an embarrassing wart of "technical dept". The same could be said of most "enterprise software". For them that don't know enterprise software is code for "It's 70% done and we will charge well to finish it for you"
by lovasoa on 12/31/23, 11:49 AM
> They wanted truly custom functionality that the low-code solution could not handle.
It's important that the low-code solution has an escape hatch, or a way to to interact with external "high-code" APIs. In sqlpage, we have sqlpage.exec
> They implemented a bunch of custom functionality in a product-specific or even proprietary language and now their pool of potential developer talent is tiny.
I agree that low-code makes sense only if the low code is in a standard, popular language. In SQLPage, it's all just SQL.
> Upgrades to the low-code platform would break their custom implementation.
This is a true problem. The low-code solution really has to be careful with updates.
> The underlying database structure was an absolute mess, especially after a bunch of incremental modifications
This! Most low-code tools take your data hostage. You shouldn't use them. In SQLPage, we add a layer on top of a database that you still fully control.
by arey_abhishek on 12/31/23, 4:01 PM
It's crucial to understand the advantages of low-code for specific situations, especially in developing internal applications. These tools, often neglected due to limited resources or developer disinterest, can be rapidly and effectively created with low-code solutions. Low-code excels in scenarios where internal teams are overwhelmed and business users face long waits for features. Although it's not a cure-all, low-code is highly effective for certain tasks where speed and ease are key, despite sometimes facing limitations in customization.
Some modern low code tools are also evolving to be closer to web frameworks. Plasmic is one my favourite examples of this.
by jbsmith1 on 12/31/23, 12:21 AM
by peteforde on 12/30/23, 11:37 PM
I think that GPT-4 today is good enough to replace about 80% of programmers in the right hands. Put differently: we probably don't need bootcamp grads anymore. The folks who keep their jobs are the ones who intuitively grasp what needs to be done, how to break that ask down into iterative tasks, and how to word those tasks as prompts.
Instead of scrambling to replace application stacks with layers of dumbed down abstractions, we are actually replacing the less experienced people working with application stacks.
Dramatically better outcome for everyone but the people who thought they could take a bootcamp and create generational wealth.
by merelysounds on 12/31/23, 9:21 AM
by outlore on 12/31/23, 1:39 AM
However, I share the author's skepticism about other low-code tools that involve a lot of UI/visual flow building with limited insight into how the black box works and what its constraints are.
by j45 on 12/30/23, 10:53 PM
As the other comment said, less code tools for developers can be quite helpful.
by b33j0r on 12/31/23, 4:55 AM
I see this being our reality anyway. In many cases; not all.
You can’t ask the LLM, nor a hypothetical AGI, nor anything, to build the aqueducts. Especially if you don’t know you need them. And they won’t solve the problem if neither a human nor an AI know what the problems actually are. Let’s make em out of lead!
And they definitely won’t waste tokens on a postgres rollback migration unless we make that essential in the acceptance criteria.
An LLM is all of our ideas, in a search UI that dang nearly passes the turing test. (That says more about us than the state of AI technology.)
We are pattern machines in many ways, and many things we code are even lovingly called Software Patterns. The promise is not that software engineering goes away, it’s that we’ll all be managers for a while.
Low-code, to me, is different from “statistically generated solutions that pass the requirements.” Genetic programming was an idea for decades, but that is also different from stuff that combines yours and my most relevant github commits into a 90% best guess. Not random, hoping for the best, in this regime. Educated guess.
by ejb999 on 12/31/23, 12:14 PM
I suspect there is another opportunity coming along to make some good money bailing out folks who built 'no code' solutions that their business now depends on, but no longer meets the needs and has become to fragmented and complicated to tinker with and difficult to change, scale or adapt.
That said, I am not opposed to no-code - it is a good and often inexpensive way to solve some problems, or at least get a POC working - many of those solutions may never need to scale or adapt.
...but some will, and thus the coming opportunity.
by cirgue on 12/30/23, 11:01 PM
by jauntywundrkind on 12/30/23, 11:56 PM
Any area of code itself is usually fairly boring & irrelevant. It's systems that accrue mass & complexity. Low code systems sound good by demonizing the weird symbols & incantations that make up the lower level fo coding, but it's this systematic complexity, it's the aggregation of many things happening that makes things opaque & difficult.
Finding patterns to suss out broader-scale understanding is what really tempts me. I don't have super strong vision here, but I'm interested in projects like Node-RED, or even to a degree works like jBPM. Both kind of speak to going beyond coding, but I think the valuable thing here is really that they are assembly toolkits for modules of code & data. They are just examples and not even good ones but this quest, to me, to get to the next levels of computing, is to make clearer portraits of what happens, that either are above to code level, or where the code's running creates higher level observability surfaces.
Code is so easy to demonize. The layering is often so implicit, handlers and DAOs and routes in different layers maybe but with no clear overview layer. Figuring out how to make legible these systems, without diving deep into the code, is what, I think, will make systems less intimidating & will serve as a bridge to make businessfolk and novides better able to intuitively grasp & meddle with these these artificed put before them, with courage. And making people less afraid of the machine, more interested in peeking in and meddling, that's where so much hope lies.
by hm-nah on 12/31/23, 5:46 PM
Give an analyst with some technical acumen PowerApps and ask them to mock up requirements, and after awhile, they can produce a click-through prototype.
That same analyst will likely improve their UI, API, JSON and SQL skills in the meantime.
Low-code tools are also good for digitizing CRUD forms.
Much beyond that and things get very proprietary, very fast.
by danjc on 12/31/23, 6:34 AM
We're a low code platform (app integration) and what's worked well for us is to have the platform store the generated workflow design (yaml/json) in source control.
Additionally, we map environments on to source control branches so merging to a branch is what promotes a design version to qa or prod.
by tdeck on 12/31/23, 3:00 AM
Aside: The contrast on this website is really borderline. Extremely light gray, low font weight, white background. I thought we were past that particular trend in web design.
by smitty1e on 12/30/23, 11:02 PM
This falls apart when:
* legacy systems/data must be integrated
* the requirements get interesting
There is just no substitute for a good working understanding of the tools, and that means staff that can go past the low-code facade when needful.
by skeeter2020 on 12/31/23, 2:47 PM
The 80% is not evenly distributed. Marketing might have problems that are 95% satisfied by low-code and they can change their process for the last 5%, or accounting can do 100% of a 50% subset of their job with low-code. Logistics can't really do any of their job so they steer clear.
All the other points are related to trying to satisfy 100% of a custom problem with a generic low code framework. Don't do that.
You run into all of these problems with custom code solutions too; The debate should be about investment vs. control, of which no/low/custom coding is a component but not the differentiator as presented here.
by rubin55 on 12/31/23, 4:15 PM
The story is exactly like the fine article mentions. Heavy reliance on proprietary stuff making the organization heavily reliant on very expensive consultants to get stuff done, no way to sanely version things..
I now go out of my way to avoid working rescue jobs like these, unless the client is actively migrating away from them.
by tyingq on 12/31/23, 3:03 PM
by hacknews20 on 1/1/24, 1:15 AM
by redleader55 on 12/31/23, 10:40 AM
by 29athrowaway on 12/31/23, 5:32 AM
by intrasight on 1/1/24, 3:33 AM
Likewise an upgrade would break our custom SAP implementation. Most all big ticket business apps are "low code" and suffer this problem.
>The underlying database structure was an absolute mess, especially after a bunch of incremental modifications.
Ditto with all enterprise software I have used.
All big businesses depend on low code enterprise apps. For that matter, a SQL database is a low-code platform.
by nickfromseattle on 12/31/23, 6:35 PM
It can't do everything we'd like, but there is always a workaround that is "good enough".
by andrewstuart on 12/31/23, 4:03 AM
Sure it had limitations but you could get an awful lot done within those limitations.
by kukkeliskuu on 12/31/23, 9:42 AM
by Poliorcetes on 12/31/23, 9:16 PM
then there is also labview, the programs for the equipment were mostly made by former students in that program
low-code is old as dirt by now
by alserio on 12/31/23, 10:45 AM
by astrobe_ on 12/31/23, 5:15 PM
by zzzeek on 12/31/23, 2:04 AM
googled.
OH, it's those stupid visual IDEs that pretend you can connect blocks and lines together and get a program.
"I would get clients who had been drawn to low-code all the time for the promise of fast development time and low maintenance cost."
Oh I'd not go anywhere near silly "clients" like that. Who wants to fight with that level of dumb
by gregd on 12/31/23, 3:11 PM
Sure, you can view your Dataverse database in SSMS, but it's read only and you get no autocomplete.
And don't even get me started on XRM Toolbox.
by EntICOnc on 1/1/24, 1:32 PM
https://www.i-programmer.info/professional-programmer/103-i-...
found that " that low code platforms, while allowing for fast learning development processes, enabling a more systemic view of software projects and providing easy integration with other application endpoints, can't escape good Software Engineering, as low code's inherent abstraction requires following good development practices"
So no matter,you have to a developer and not just citizen developer
by talldatethrow on 12/31/23, 12:02 AM
by FrustratedMonky on 12/31/23, 4:49 PM
C is the low code version of Assembly
Python is low code version of C
Some visual basic like thing is low code Python
WordPress
a million other web tools
Etc...
But in the end, someone with a 'programmer' mindset, that can understand problem solving, is needed to make it work, at whatever level we are at.
by prakashn27 on 12/31/23, 4:24 AM
Low code may be better for mvp. Once you have enough revenue moving to a code based solution will be better in long run.
by djangelic on 12/30/23, 11:04 PM
by Poliorcetes on 12/31/23, 12:42 PM
There is a comparison here to be made with ascii graphics and they could be quite charming, dwarf fortress for example looks great but there is only so much you can do with text
some languages it seems to me are running out of symbols and their meaning is not obvious at the glance, for example what is the meaning of ', @, $, !: in diffent languages? why should it have that meaning
in the end code is much more logical and better understood if it is a diagram of blocks, after all that what code is supposed to represent, a series of decisions that lead to a desired state in the data
by hackerdad on 12/31/23, 9:16 AM
tools focusing in low-code does not solve them and the tool that solves typically don't market them as low-code - because the are not. low code comes as a result.
by zubairq on 12/31/23, 6:37 AM
I would be interested to know which low code tools the blog author has actually used, and what they see as the viable alternatives are?
by hiAndrewQuinn on 12/31/23, 12:11 PM
by maccard on 12/31/23, 1:31 AM
by anonymous344 on 12/31/23, 12:28 PM
what seemed to be true that you can easily build a gui that will break in the next months and only have terrible default ui-elements, like calendar selector you cannot really prevent going past time or 99 other akward user interface gimmicks.
why should company try to save 2000$ on development, but then loose 10-100$ every single day with bad usability?
by nixpulvis on 12/30/23, 11:01 PM
by cassepipe on 12/31/23, 1:35 AM
Wordpress, Excel ?
by lerpgame on 12/31/23, 3:27 PM
by uraura on 12/31/23, 12:32 AM
by noobermin on 12/31/23, 9:33 AM
by Poliorcetes on 12/31/23, 3:18 PM
is there any of them out there?
all i see is proprietary software with hefty prices
by zby on 12/31/23, 11:29 AM
by ChrisMarshallNY on 12/31/23, 12:19 AM
Is it a programming language, a framework, a compiler/linker/IDL, etc.?
I mean, there are some that could argue that C is "low code," because it isn't Machine Code.
I started in Machine Code, and, these days, write mostly in Swift. Swift seems like "low code," compared to Machine Code.
I assume that they are talking about things like Qt, React Native, Xamarin, Electron, or Ionic (You can tell that I develop host apps).
I write native Apple, using established Interface Builder SDKs, mainly because of the first point. I like to have 100%, and Highest Common Denominator approaches don't allow that.
Also, I find that upgrading can be a problem. I have been in the position of not being able to support the latest OS, because a library hadn't been updated, yet.
by syndicatedjelly on 1/1/24, 1:30 AM
This is on top of the $1 million/year licensing fee for the proprietary tool in all its own glory. This included a:
- proprietary, closed-source database
- proprietary, closed-source scripting language
- proprietary, closed-source "CI/CD" (more like, barf out some arbitrary, insecure mash of HTML, CSS, and Javascript into the browser)
We spent a significant amount of time trying to peer under the hood. Except, it was more like we were trying to rip the head off the cylinder block with a bunch of vice grips, and then safely put it back together. I cringe thinking back to the tactics we used to "research" - it was like hitting an engine with a hammer and trying to figure out what it does. We came up with all sorts of theories about hammers, about sounds that engines make when hit with hammers. But it was a complete waste of time. That's not how you study an engine. No transferable skills are learned in the process.
I try to make sense of my time there - I'm only a few years removed from that job still. I sometimes feel embarrassed that I didn't get out of there sooner. Why did it take me so long to figure out my software career would go nowhere if I worked on stuff like that?
I'm in a much better place now, working on good software in real languages with smart people. My skills have grown unbelievably in just a short space of time.
===
Low-code applications are worse than what everyone is saying. They are career-destroyers. It's okay to dip your toes in the water. But it's too easy to become reliant. You'll find that database details, CI/CD, even version control are handled by some mythical low-code tools that you don't understand (and can't configure).
Work on software where the company is in full control of every line of business logic they own. You might own only one small slice of the software, but it's so much easier to sleep at night knowing that every bite of the pie can be fine-tuned according to SOMEONE at the company.
by dventimi on 12/30/23, 11:48 PM
by brucenanner on 12/31/23, 4:54 AM
by iamleppert on 12/31/23, 4:43 PM