When we started experimenting with Docker and Kubernetes, we were just looking for a more efficient way to stand up our applications. Traditionally, it’s an infrastructure or operations team’s responsibility to make sure every dependency an application needs to run is set up the server, and that none of them are in conflict — and then continue to ensure that throughout the life of the system. It’s also their responsibility to figure out which server the application need to go on in the first place.
It’s weird to call a process a perk, but our focus on reusable code is one of my favorite things about working at Table XI. Limiting ourselves to the absolute fewest number of components to build software is a challenge, and it’s one that’s made me a better developer.
Infrastructure is the framework running under your entire business — so it only makes sense that an infrastructure audit would look at the whole picture. If your infrastructure touches your email, applications, timesheets, employee communication and anything else, the audit should as well.
Every industry has a human element, but designing for healthcare means understanding that connection is the heart of medicine. All the new medicines and advancing technologies in healthcare mean nothing without the interactions between doctors and patients. When a person walks in complaining of an ache or pain, it’s the doctor’s job to use their knowledge and intuition to tease out details and offer a diagnosis. That process is intrinsic to the profession, and it’s why the doctor-patient relationship is so sacred.
It’s also the same process we use when building software for healthcare providers.
If you’ve been working in medicine for decades, it can be a bit of a shock when all of the sudden you’re tasked with building software for healthcare providers. It’s an entirely new discipline, with different possibilities, different norms, even a different language.
The truth, though, is that the best hospital software starts with you.
There’s always a learning curve when any industry turns to healthcare software companies, but it’s a particularly deep chasm between tech and medicine. Both sides are highly technical, but that’s where the similarities stop — different cultures, different languages, different expectations about the role of software in healthcare.
Success depends on building effective bridges.
My original goal was not learning React Native. I was just hoping to get better at JavaScript, and React seemed like a good way to do it. Then our mobile team was shorthanded, and when I looked at one of their React Native Github repos, it looked familiar enough to jump in and try to help out.
One year later, and I would say 60 percent of my time is spent building React Native apps.
We developed our React Native stack because we’re constantly trying to find tools that will make our products better. Any time we hear about a new tool or technique, our mobile team has a process for testing them out. If it proves out – delivering value to our clients — we’re quick to work it into our stack.
Software risk haunts every development project. And yet we almost never talk about it. Every project manager focuses on the same big three constraints when putting together a proposal: scope, timeline and budget. For all three, you’ll get fancy graphs and analytics, a full, quantified representation.
Then software risks come in and blow it all apart.
Every time we start an engagement, we sit down with our new partner to decide whether to build vs. buy software. It’s not something development shops typically do. We like our “hammer” of custom software solutions, but to be good consultants, we can’t treat every project like it’s a nail.
That’s why we help every partner weigh the advantages of buying software versus building. If we can find existing technology that meets their needs, we can save them tens of thousands of dollars.
328 S. Jefferson St.
Suite 670
Chicago, IL 60661
312.450.6320
Workshops
Give your team new problem-solving techniques with our innovating workshops and check out our event series.
