sixdimensional

There are two components to your question - the practical side, "how do I build a workflow system?" and then, "why Petri nets?".

If you really want to build a generic workflow engine, I think the way is to identify the pattern they follow and implement that. Build classes, attributes and methods that abstract away automating a process in a generic sense (e.g. turn workflow into one or more services) and then integrate those service(s) into your application as the glue that holds together complex processes. It's obviously harder than that one sentence, of course there are lots of nuances, but that's probably the simplest way I can think of to explain the high-level hand-wavy approach to doing this if you want to build it yourself, without going into all the details.

If you understand the pattern, and would rather not build, but buy or obtain an open source workflow engine/management system, many exist [1][2]. Most enterprise applications (e.g. Oracle, SAP, Salesforce, etc. etc.) have such workflow tools built in already.

Regarding the second part of your question, "why Petri nets?", well, one could argue that any system that automates a process in any way is a kind of workflow management system/engine or could be modelled as a "Petri net". I guess you could say, "why care about patterns in software engineering" then? The difference is, like many patterns, Petri nets give you a tried/tested technique for conceptualizing and modelling the system/process, validating its correctness, and in some cases, tools/engines that implement these concepts can even give you the executable framework for building too. You know, standing on the shoulders of giants and that kind of thing.

Technically, Petri nets are a superset for modelling/designing/visualizing/validating what you can do in a workflow system. Also, to be clear, the concept of Petri nets is in every way compatible with/related to object oriented design, and even functional and procedural programming paradigms.

Perhaps I can try to answer your question in this way.. by relating Petri nets to design patterns in software engineering (think, Gang of Four, Patterns of Enterprise Architecture, etc.). You know how, when you're developing software - over the years, you start to see patterns emerge? The best way to understand Petri nets and how they relate is to see what problem they solve in work you might have done yourself.

If you have ever implemented a large chunk of any information system, you start to realize, that even though it might be comprised of many smaller components working together, ultimately, it had to enable some kind of overall process to function. And how, there were certain core components that you realize are more infrastructural in nature and are re-usable? For example, logging, security (AAA, authentication, authorization, access control), etc.?

I was exposed to workflow systems when I first started working on case management systems (for example, legal cases). Case management is a scenario that includes, coordinating multiple child processes to build a "case", which is an instance of a process that is being executed. Think.. Case ID #123 is an instance of a distributed process, which results in a case file, but may have many independent and ancillary sub-processes, approvals, communications, notes, reviews, etc. that must come together to "complete" the case.

You might diagram the flow of that legal process in a "flow chart". Business people love flowcharts right? The next logical step is to think of.. what if these flow charts could represent/become computable models (e.g. math/validity/correctness) and perhaps even a shell of executable code?

You could construct an entire monolithic case management system, that handled all the work related to legal cases - by learning the business process, hard-coding the logic from that flow chart (classes with attributes and methods that define the full behavior of the system, interactions, etc. if we were doing OOP), and so on. If you did that, and you did that reasonably well, that system would certainly work for its designated scenario (legal cases).

In the midst of doing that, you might have realized that, the IT ticketing system you bought for your organization, had a similar process (for example, case management in ITIL). You might notice.. startling similarities between the basic design of that system and the legal case management one.. to the point where you start asking.. is there a pattern here?

Sure enough, there is one. The basis for that pattern is what some call workflow patterns - Professor Wil van der Aalst and Professor Arthur ter Hofstede being two influential thinkers in the area [3]. If we follow this thread, we find one helpful paper: "The Application of Petri Nets to Workflow Management" [4] ,which I think would be of interest.

Then we start to realize that, some processes don't happen in a monolithic way. They need to be "consistent", but the underlying code and execution could be distributed in different services or different systems and yet our process needs to pull it altogether to carry out the work of the process. We might see that even though distributed, these processes and systems could be represented holistically. Petri nets help in this situation.

I think one thing people might have missed when we got into this whole world of federated, independent teams, service-oriented architecture and now microservices, was that - ultimately, systematic behavior and processes must still function, and function well enough for organizations to fulfill their purpose. While self-emergent behaviors are entirely possible and arise all the time, in complex systems.. when you absolutely must make your system/process work, you need a way to engineer that and Petri nets give you a way to think about, model, and validate/reason about that.

For a current very relevant example, consider microservices today. On their own, they provide little value - but when orchestrated and working together to compose a larger system, to enable human and machine processes to execute and thrive, it would be nice to have ways to think about and model those processes that live on top. Petri nets are one way to conceptualize and visualize those processes, where that conceptual model can be proven to be sound mathematically, and even turned in some cases directly into an executable framework within which to plug in your own code. That's what workflow systems often do, for example.

Another relevant and recent case - event sourcing.. and event-driven mechanisms, and event handling, and the processing that goes along with it to essentially create a "directed process" - these are all directly related too. Also, there's a reason that data workflow automations such as Apache Spark or Airflow, for example, chose directed acyclic graphs (DAG) as models for complex, reliable, distributed process execution - and you can represent those as Petri nets too.

What I always liked about Petri nets when I discovered them, was it gave me a way to link together strict state management, with process control, based in logical/provable theory - but also gave me a way to bridge between the "human" side of process ("flow charts") and the technical side of things. It gave me a framework to "plug in" my different systems, functions, services, objects and behaviors into something that coordinated complex process both in theory and in practice.

I do not believe that one must implement monolithic process in code - as there is also emergent behavior - but, Petri nets and workflow management systems give you a way to think conceptually about how your system works.. and even potentially to build the "glue" that puts your system together, if you chose.

By the way, one interesting thing I saw that came out of this work, was simulation software where you could use Petri nets to essentially "run" a process in a simulated way and see if there were any natural bottlenecks in the process that you could optimize in advance - before building any code at all. Process simulation [5] is another whole related rabbit hole to go down, but a fascinating one!

[1] https://en.wikipedia.org/wiki/Workflow_management_system

[2] https://github.com/meirwah/awesome-workflow-engines

[3] http://www.workflowpatterns.com/

[4] https://www.semanticscholar.org/paper/The-Application-of-Pet...

[5] https://en.wikipedia.org/wiki/Process_simulation

No post on state machines would be complete without mention of the superset concept of Petri nets [1]. I have used Petri nets to build my own workflow engine previously. Building a workflow engine is one of those things... nearly every enterprise app has one, and normally you shouldn’t need to build one if you can source one... but it is an exercise that makes you a stronger engineer/developer too, deepening understanding of the patterns that lie beneath most systems.

Back when I was building, openly available workflow engines, BPML, BPEL etc. were not really a thing yet, so it made a little more sense to be building one.

[1] https://en.wikipedia.org/wiki/Petri_net

XLL lets you also write .NET code, basically anything that can compile to a DLL, to make custom functions you can expose in Excel - and it is a pretty old supported integration method by Microsoft with Excel. COM enabled DLLs were another way to do this, but they ran slower.

Not that I have any issue with getting Python in my Excel, but people seem to forget that .NET is also an option.

Getting these capabilities enabled in a locked down corporate IT environment traditionally was difficult but I suspect that is changing.

I have also lived the whole, turning a model in Excel into an app exercise. At the time, we rewrote a fairly complex demand planning app from Excel/VBA to C# since the other dev team members were C# devs and could support the app.

However, during the project, I did a demo of how one could build a Winforms app in VB.NET also, to the developer who was the Excel/VBA guru. He'd had no idea that coding in VB.NET and Winforms was close enough that he nearly could have been doing that instead.

The compiled C# version of the model we built, went from running a single instance of the model in 1 hour, to under 1 minute. We could re-run their model for tens of thousands of instances daily, without breaking a sweat.

Ironically, the rewritten version in C# never saw the light of day as the project was canceled (corporate politics and wisdom). However, the simple optimizations we identified in the rewrite were given to the Excel guru who actually made improvements to his tool that let it run in more like 10 minutes.. and it was even object oriented and modular! He learned he could do a lot more in Excel/VBA that he didn't even know about.

Coding is coding.. just some tools make the jobs easier or harder.

An interesting thought - cars are becoming an appliance and offered -aaS (as a service). Could Apple also disrupt the offering model for cars with an entrance into this market?

Hi the_only_law,

I don't want to suggest that what I have observed is scientific truth. Lately, I have been going to therapy regularly to try to work things out. I think it's helping, it certainly isn't hurting, to have a carved out time with somebody neutral to just think and talk.

Within that sentence is a pattern I have noticed in my life at least. I went through depressive periods a few times in my life for different reasons (and sometimes seemingly no reason). Divorce, losing a job and unexpected unemployment for a longer time frame, etc.

This created gaps in my career life, and each time I had a gap, there was carryover effect from the event that triggered it, which I needed to get through. The first few times it happened, I didn't realize that I actually needed the gap, to have time to process. I didn't realize that my brain, although depressed, well... it almost felt like it was doing what it was doing on purpose. Almost like, to force me to rest and sleep and sort of stagger aimlessly through the world for a while.

Only one time when this happened, before I was getting therapy, I saw that things were going sideways again and I was going to have a gap. This time, I prepared myself for it by telling myself that, if I was aimless, bored, did nothing, etc that it was OK. That I would allow myself to do that for a reasonable period of time until I started to feel better, and then after that I could do whatever I wanted.

I guess what I'm saying is, I let it happen consciously and gave myself time. I let that time be carved out to take a break.

After about 6 months went by, I am not sure what exactly changed, but something changed and I just started feeling better. It wasn't any one specific thing, but I was sitting there and started to get the natural inclination to just go start toying around again, this time even with some different and new subject areas, learning some new stuff and soon enough that transitioned into maybe starting my own business.

I was so excited and had begun the process, when, about two weeks into doing it, a job offer I knew nothing about appeared. I took a hard left turn and took the job because it sounded interesting, and my story continued.

I want to reintroduce the world to the word sabbatical [1] - rest from work. Carving out time, or taking advantage of the gaps. Rest with intent.

Depression is real. When life takes a toll there are chemical changes in the brain. Therapy and medication could be necessary and so if you need help, the advice is always to seek professional help. Don't suffer alone if you need help.

If, like me, you find a way to process it safely on your own, as I did in the last 6 month gap, you may find your way through.

If it is of any help, think on what a sabbatical is and if you can swing it, try it. It does not mean you must do nothing at all, take a break, learn something if you like, but don't push yourself to do anything that feels like "work".

I genuinely believe and have even considered starting some kind of non-profit support organization to help people learn about, organize and implement a sabbatical. I may still do it, after realizing that this is an area where we are really suffering as humans and where we need support.

Best wishes on your journey, be safe, and good luck.

[1] https://en.wikipedia.org/wiki/Sabbatical

Thinking in terms of building physical buildings.. architects are often the visionaries but engineers are the realists. You know, architects come up with these crazy incredible building designs based on their engineering understanding, but ultimately it has to be vetted, proven and implemented by engineers.

I have, however, always wondered why people should be seen as "only architects" and "only engineers". While the separation of duties is critical to ensure the overall construction is sound, people can be visionary engineers, and people can be knowledgeable in both how to do something in real terms as well as dreaming on how to go beyond.

It sounds like this would have made a better proof of concept than an commitment to the architecture.

The idea on the face of it is not per se a bad one, quite interesting, but the implementations are perhaps not there yet to back such an idea.

It's important to know as an architect when your vision for the architecture is outpacing reality, to know your time horizon, and match the vision with the tools that help you implement the actual use cases you have in your hand right now.

It sounds like this person might have had an interesting idea but not a working system. In another light, this could have been a good idea if all the technology was in place to support it.. but the timing and implementation doesn't sound like it was right, perhaps.

The old saying "use the right tool for the job" comes to mind, but that can be hard to see when the tools are changing so fast, and there is a risk to going too far onto the bleeding edge. Perhaps the saying should have been, "use the rightest tool you can find at the time, that gives you some room to grow, for the job"...

Blockchain databases take this model to the extreme - it is a database that is append only and immutable, with cryptographic guarantees of the ledger.

I'm not selling any particular tool but Amazon's QLDB is an interesting example of a blockchain-based database. I am interested to see how things like Kafka and this might come together somehow.

In my opinion, we have evolved to a point where storage is not a concern for temporal use cases - i.e. we can now store every change in an immutable fashion. When you think about this being an append only transaction log that you never have to purge, and you make observable events on that log (which is what most CDC systems do)... yeah it works. Now you have every change, cryptographically secure, with events to trigger downstream consumers and you can really rethink the whole architecture of monolithic databases vs. data platforms.

It is an exciting time we are in, in my opinion.

CQRS

Look into the patterns of CQRS, event sourcing, flow based programming and materialized views. GraphQL is an interface layer, but you still have to solve for the layer below.

API composition only works when the network boundary and services are performance compatible to federate queries. The patterns above can be used to work around the performance concern at a cost of system complexity.

I actually really think that the way Bayesian probability factors in subjective probability is key, in that even if an algorithm spits out a result, it is still subject to human interpretation as well. I think some kind of composite decision support with both purely objective results (e.g. neural networks or other models that are purely machine based) as well as subjective beliefs could be really interesting and I still haven't seen much that does this.

I think maybe reinforcement learning where human feedback becomes part of the loop is about as close as I could think of. But that is different than factoring in human input to probability calculations.

So what education do we need to know how to utilize total freedom of speech in a civil manner?

In other words, what needs to be taught/learned that everyone can understand globally and across cultures which helps humanity understand how to get the maximum benefit from this technology and protect oneself from the negative impacts?

I mean this honestly and literally, what would you tell or teach people? What would an educational program for this look like? What would it look like for all ages, and cultures and how could we make it universal? Is it even possible?

I feel the best way to harness the power and control the outcome in the longest run is to evolve our understanding with intent.

Because absolute freedom means without restriction and can tend towards chaos, how do we train humanity???

Maybe I'm on a tangent but I am not sure how to answer this question myself.

One thing that came to mind was secular ethics but that is far too complicated to teach directly. And I am not sure if there is any cultural bias in that idea as well.

I guess I'm thinking.. teach, learn and evolve while trying not to force control. I realize even writing it how impossible that sounds, but should we put our energy into cracking this problem?

As much as I sometimes wish I could be rewarded just a bit better for going above and beyond, I have to agree with you here. I appreciate your philosophy.

Ultimately, intrinsic motivation won’t always make us rich, but it might help us be happy and fulfilled. And in the rare occasion that health, wealth and happiness all align, what a good life we can enjoy.

Here here!

I like the direction you guys seem to be taking here with Supabase.

Regarding the comment about subscription-based DB engine and denormalization, I posted this [1] on the post about Materialize although I don't think anyone read it.

I am right there that there is a new unified data architecture evolving and I think it is difficult but doable. CQRS and event-sourcing are core elements and the decoupling of the database continues. I also believe Flow Based Programming [2] and reactive programming (observables on top of streams of events) are other key concepts.

I've worked on federated database query engines and it turns out that federation has some relationships to this problem. I recently saw this article about Netflix's approach to federated GraphQL (which to me feels like API composition) and found it interesting [3].

I don't know if anything of this helps you but hope it might :)

I don't claim to be an expert here but if you're interested in talking more, my email's in my profile.

[1] https://news.ycombinator.com/item?id=25285890

[2] https://wiki.c2.com/?FlowBasedProgramming

[3] https://netflixtechblog.com/how-netflix-scales-its-api-with-...

I almost can't believe we are talking about this now. I mean that in the sense of, I have built applications every possible way - when you work in a big company and inherit one of everything, you have to do that often.

In my past, I built one application that was fully database driven, and at the time (2004-2005) it would have been difficult to pull off without stored procedures and table driven logic - fully maximizing the power of SQL - especially in the timeframe I had to do it (<3 months). I mean, I pushed the technology HARD (expert system for fraud detection that worked hand-in-hand with basic machine learning).

I will never forget how I was derided by people for that choice - even though, that system is still running today and working well, in the bowels of an acquirer. I mean, literally, I was derided to the point of getting imposter syndrome for feeling that I made a choice that others regarded as so limiting.

The truth is, I learned everything else about distributed applications and databases because of being derided in that way. Ultimately, I now know how to architect things many different ways and can choose when I feel it is appropriate. I also know not to let the negativity of others prevent success.

I am not sure the moral of this story. If you can build a system, and it serves its purpose well and for a long time, and it works and provides the needed value.. it really may not matter. But, you can choose sometimes, and if there is one truth it must be that there is not always only one way to do something. Try to pick the right tool for the job as best as you are able.

Don't think you're dumb just because other people don't like your idea. Keep your mind open, and be willing to learn, but if you can make it work, and prove it works, you are just as right as anyone else.

Maybe that's the moral of the story.

Don’t forget to keep your eyes on the architectural concept of Command Query Record Separation (CQRS).

When combined with event sourcing [1], there is a new unified architecture possible that solves the problem that microservices create by fragmenting data [2], and performant querying on data updating in real time.

This architecture represents more complexity but increased flexibility.

I recently saw this article about federated GraphQL [3], and while a cool idea and probably the ultimate solution (API composition), I expect that with network and physical boundaries between services still adding latency, we need materialized views as part of the architecture to compensate for the overhead of bringing together aggregate root objects from multiple systems.

[1] https://www.confluent.io/blog/event-sourcing-cqrs-stream-pro...

[2] https://microservices.io/patterns/data/cqrs.html

[3] https://netflixtechblog.com/how-netflix-scales-its-api-with-...

Only so long as you are able to easily interop one tool from one cloud with the others without major consequences. If that was true, then you can freely mix and match cloud services from different vendors.

Alas, this relies on many things, not the least of which are peering agreements between cloud vendors that do not punish the consumer for using a service on one cloud with services from another.

It is possible to an extent today, but for competitive reasons, cloud companies do not seem to have a built in incentive to collaborate. Perhaps the cost of switching and lock-in will force cloud providers to work together in the long one, else they risk alienating customers, and then lack the ability to capture a larger market.

In other words, competition is good as long as people can realistically take advantage of it. I think cloud vendors have an obligation to see that this competition is encouraged and supported.

Then you might be even more surprised to find out that Foreign Data Wrappers are Postgres' implementation of the ANSI SQL standard extension known as "SQL/MED" [1], where MED stands for "management of external data".

I spent a number of years working on a data federation/virtualization engine - and SQL/MED is very much related to that.

It's actually a relatively unknown topic by many software/data engineers I have worked with, but things like GraphQL federation (example, Apollo GraphQL) or some of the more popular tools such as Presto, Dremio, Denodo, etc.) are where more advanced versions of this are today.

SQL/MED and what Postgres can do is quite cool, but just know that any time you have system boundaries you cross (e.g. between heterogenous systems), things like joins, data types, and many other things becoming a bit more difficult - or you just have to think about them more. But very cool tech.

I've used SQL/MED in Postgres, FDW, linked servers in SQL Server, database links in Oracle, and more advanced virtualization/federation engines also.

If you haven't been exposed to this area before, highly recommended as another tool to know about for the toolkit.

[1] https://en.wikipedia.org/wiki/SQL/MED

Ok, armchair theory here, let's for a moment assume Einstein's belief that time is the fourth dimension.

We use our senses to detect/experience dimensions, right? I mean, we use sight, hearing, touch to detect 3-D space, for example (not forgetting taste and smell too).

If time is the fourth dimension, maybe these cells are our evolutionary attempt to sense/detect and operate within that dimension.

Which explains how the experience of time travel could be possible in at least one way - if we can change/affect our sense/perception of time (um.. navigating time?), it can seem to us like time travel. I'm not saying we would be affecting the timeline itself in this case, I mean more like messing with the sense of time that causes us to "experience" time travel.

Ok sorry, that does too sound like too much armchair pseudoscience, but this article and some of the other comments just got me thinking.

Perhaps the information "explosion", "deluge" or "overload" is part of it. There is so much - or too much - information, we can still ingest a lot, maybe we rely on making the connections and finding the generalities/mental models because there are too many specifics.

I once took a class in college, “Cars and Culture”. I never forgot a line from that class - that “cars provided an extension of our legs”.

Ever since then, I have told many people and thought to myself many times, that tools, take Google for instance (search and indexing), knowledge management systems (Wiki and other techniques) - these are all extensions of our brains.

We evolve with technology, and it evolves with us. We might be losing our ability to remember, but if it is because we don’t “need” to remember because technology has augmented us... Well, this is why I also am fond of telling people that I have a difficult time separating technology from nature. Even though the two don’t seem like the same thing, technology too becomes part of the natural ecosystem as organisms invent and rely on it.

Also, another way of thinking about this is, maybe the ability to recall small detailed facts was evolutionarily less important than building models in our brains. So, we offloaded recording small facts, while I think we still ingest and build/train our neural nets just fine in our brains.

Then the only problem I see is, if life becomes all about mental models, when our ability to form new mental models degrades with age, what then? Especially with the rate of technological change, I do see a real likelihood that old mental models get left behind and without the ability to adapt, organisms (i.e.) us could be hosed.

Edit: ..and the last sentence could be why the big push for AI and machine learning too - to ensure the models get encoded into the technology too... and be discovered faster, changed more fluidly, etc. Another evolutionary tool.

Hmm, legal framework, maybe... but maybe with some small tweaks the legal framework wouldn't need much changed...

If you become a contractor rather than a full time employee, the only thing you're missing is benefits/retirement probably, in addition to longer term commitments from an organization (maybe - these days there are no real guarantees).

If you can get benefits/retirement through some other kind of government program or join an independent group that forms together (I remember there was a YC company that was doing this) to pay for group benefits - then why not just go the contractor route?

I have a whole smattering of thoughts based on the article and your comment...

From the article: "The authors say the most successful companies learn from early uses of AI and adapt their business practices based on the results."

This sounds exactly like the advice that ERP companies used to recommend to organizations. Don't try to customize the ERP, adapt your business to the out-of-the-box best practices. Those who don't often face huge costs and pain trying to adapt the tool to the business, rather than the other way around.

Interestingly, this might say more about organizational culture that encourages adaptation than anything else. It has been said (I think Steven Hawking may have been the one) that "adaptability is intelligence" [1].

From your comment: "Per Conway's law, no organization wants to reorganize itself to use a new technology like software, they want to make the new technology an imitation of itself, old wine in 5% more efficient new skins. It takes either intense near-death-experiences (see: remote working/corona) to force a shift, or starting up new businesses or units to be born-digital."

Conway's Law is about how the design of an organization's information systems often mirror their communication patterns. I have seen this myself to be quite realistic, anecdotally... although.. isn't this really kind of sad in a way? First of all, I see this as an excuse to write off groups of people as "legacy" and "outdated" - for example, digital transformation seems to be as much about a generational shift as it is a technological one. Or perhaps it is just showing the way - change culture/communication - value adaptability - to change systems.

Laws were meant to be broken, so why the belief that because of Conway's law, it always has to be this way, or that Conway's law is a constraint that cannot be broken? Certainly, we won't change things if we aren't willing to adapt.

Second, regarding the recognition of it taking near-death experiences to force change - doesn't that seem true for the broader human population, not just organizations? For that matter, why do we seem to be so stubborn and unable to flip these odds in our favor? That part is frustrating.

Next, to starting new business or units to be "born-digital" - of course, I understand why people think this way, why it probably works, and why it is a go-to strategy. But there is some part of me that this is part of disposable culture, it is partly exactly what is wrong with how we approach things - instead of incremental improvement, it is burn things down or start from scratch. Because we can't adapt the designs we implement, we have to start all over.. and it seems like a wasteful exercise. Where is our logical "exnovation" (the opposite of innovation)?

Lastly, about the gap between those who become "AI-enabled" companies and actually achieve success, and those who do not. In full recognition of the reality that those who do not get with the times, often get left behind, when it comes to technology - this gap worries me more. I'm thinking here of intellectual property, and that what is the best AI model will most likely always be locked and controlled by the profit motive - and thinking, what then?

I suppose this is why some thinkers are so worried about an AI-enabled future (ex. Elon Musk or Stephen Hawking) - it's not the positive potential that scares them, it's what happens to humans [2].

[1] http://www.actinginbalance.com/intelligence-is-adaptability/

[2] https://www.washingtonpost.com/news/innovations/wp/2018/04/0...

A shortcut to storing (and possibly also querying) data is to store (or "query" within) the function of that data? Seems to be in-line with what you wrote, and in essence I've always looked at neural networks as a kind of compression into complex functions of encoded data.

I have thought that cost-based optimizers in database query planning could definitely overlap with neural network approaches. I know there are some papers in the area, but I haven't seen any implementations.

I've often wondered if one could store representations of data as regular expressions or something similar. Sounds like what you are looking for is along similar lines - data compression by effectively "compiling" the data into an expression or compact representation?

I'm really curious about this pattern of making rules and then not following them. It seems rampant and somehow fundamentally everything seems so dysfunctional.

"Denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use." [1]

[1] https://www.lexico.com/en/definition/legacy

Thank you for sharing your perspective! Good idea on doing something different from the daily job to generate the energy/drive. I should do that more often.

My only problem is I spend so much energy on work, I don't have it when I go home, no matter how excited or interested I am in the side projects.

I realize that's also a personal problem - poor time/resource allocation - not allocating a proper amount of time/energy to work vs. personal projects.

However, I can say, doing a full time, involved job and giving it all my attention tends to use up all the cycles. Is that true for other people too?