I recently demoed one and the immersive feel is insanely realistic. I was blown away. At the same time, I’m not sure how I’d use it. I had hoped it could allow having a multi-screen virtual desktop anywhere. It could, sort of. But there is enough input lag to make a power user frustrated. And after 30 minutes I was tired of wearing it. I hope they keep working on it, though. Version 3 or 4 could be when it really takes off…
This is one of the best arguments I've heard. SaaS is valuable because it's Software as a SERVICE. More often than not, the software by itself doesn't have much value without the team with deep domain knowledge supporting, maintaining, and constantly improving it.
The disadvantage is not just to early startups. I have ownership in a 9-year old small software company that has never taken investments and has managed to break even or be slightly profitable every year while growing. We reinvest revenue into a team that keeps improving the product.
In 2022 our reported "taxable income" to the IRS skyrocketed because of this rule change. Despite a small profit, we are paying tax on essentially 50% or more of our REVENUE. And because we are a pass-through entity, it pushes us into tax brackets that are quite ae bit higher than corporate tax rates of C-Corps.
2 or 3 years into this we will either have to take a loan to pay taxes, find a way to cut expenses, or (hopefully) grow enough in revenue while not increasing expenses to cover the additional tax.
It really is insanity. Our accounting firm and everyone they spoke with was convinced it would be "fixed" by congress before the final extension deadline a couple months ago. So we waited to the last minute to file, which, of course, resulted in significant late fees and interest on top of everything else.
Canopy is developing innovative software to support nationwide social impact programs. Our clients are rock stars! They are dedicated to community-focused programs, including cooperative extension, 4-H, and SNAP-Ed. We build systems to make their jobs a little easier and to help understand what works, what doesn’t, and what could be improved.
We are seeking a Software Engineer to join our talented engineering team. This is a full-stack web developer position that will work closely with other full-stack and front-end engineers. Technologies include Python, Django, MySQL, Vue.js, and AWS for hosting.
Access was pretty incredible for what it is/was. I could build a structured database with a nice UI for non-data people, reports, and even more advanced things like automated emails, exports, etc., in 1/10th or even 1/20th the time it'd take to build something similar as a web app.
We had an Access database that managed grant funding for an entire public University and in many ways it worked a lot better than the SaaS app that recently replaced it. Need to collect a new set of data? No problem, give me 4 hours and it'll be ready to use :P.
I'd love to have something like Access but that worked very well as a platform-agnostic web app and could easily integrate with cloud infrastructure.
You used to be able to do that with Access 2010 web databases. Of course, Microsoft has deprecated that in favor of Powerapps and Microsoft Dataverse, but it's not clear that actually lets you join an Access database to a low-code frontend. (It should, but there's a lot of marketing speak that I don't quite understand.)
"...failures more often come down to a misjudgment of market need, growing too fast, and overly idealistic visions (all things, notably, that VCs encourage)"
So avoiding VC funding might drastically reduce failures? :-P. There are many opportunities for niche software and services, but most would never turn into the next unicorn. If you have a validated idea that has real potential and you are willing to take a huge risk, then by all means go for VC funding and talk to places like YC. This is what they are made for, and they are good at it. However, if your idea is part of the other 99%, there may still be real opportunity to create and build a successful small business. Just set your expectations appropriately.
I'm nobody special but have co-founded 2 small software companies in the past 8 years. Both provide much-needed niche software and services. Neither has taken any investment capital, and combined they employ about 30 people while paying above average wages.
If you really want to start a company, there are other paths, especially if becoming a millionaire isn't your primary motivation.
No magic formula, but in my case I worked for a research & evaluation office at a university for a number of years. I did everything from tech support to building small databases. During that time I learned about the needs of research projects, and a few specific grant programs, which led to opportunities to build systems to automate collecting and organizing data, then expand those beyond a single use case.
I'm no expert, so don't put too much stock in this, but a few tips from my experience:
1. Don't set out to start a business, then look for an idea. Instead, look for opportunities while you gain experience in a particular industry. I had 14 years of experience in the research/grant world before co-founding my first private business.
2. (Maybe) Look for a job as an SWE or IT support person within a non-IT company. Do a great job serving others and you'll become the go-to person for solutions. By the time I started the first company, we had already built over 10 small databases to solve specific problems, but none turned into anything more than one-off solutions to streamline specific processes.
3. Work hard, persevere, have a positive attitude, and always look for ways to help and serve everyone around you. Software is just the tool to provide a service. We support our clients through the software we build, but also through a very in-depth understanding of their world and how we can best help them. You also need a support network to start and grow a business, and people are much more likely to help and support you if they value and respect you.
4. Maybe owning your own business should be a 10 or 15 year goal. I know that's probably hard for people early in their careers seeing so many others self-employed. But there's something to spending a decade learning an industry and building a network. I'm not sure either company would have been successful had I started them in my early 20s. Just because the unicorn tech companies we hear about were founded by young college drop-outs doesn't mean that's the norm.I read somewhere that the average age of small business founders is somewhere in the 40s.
That was just my path, so take it with a grain of salt. There are many paths to starting a business and you'll want to decide what you want to get out of it. For me, it was never about making lots of money. It was about building something that helps others, creating good careers for people, and having the freedom to make our own decisions.
Yes - you're right - having some prior domain knowledge or being exposed to it or partnering with folks who are is probably the most obvious one. I was hoping to hear about a shortcut ;)
RE: It was about building something that helps others, creating good careers for people, and having the freedom to make our own decisions.
Respect. Everyone chasing after Billions and trying to achieve the goal of buying yachts within yachts is not sustainable anyway. Should be more along your path... achieving happiness without needing millions and also giving back to your community.
Please don't follow this advice if you are in any kind of IT support role. It may make sense for developers who need large blocks of uninterrupted focus time, but even then the issue to resolve is working with team members on best practices for interrupting developers.
Doing nothing is akin to saying my time is more valuable than yours, you silly plebian. It's the sort of attitude that reinforces the unfortunate stereotype that IT people are arrogant and view their expertise and role as more important than others'.
I found great success providing IT support by always responding immediately when I'm available, and establishing focus times where others know I may not respond right away. An attitude of service and humility can go a long way in winning the respect and trust of your colleagues and supervisors.
I work in IT support and get tickets sent to me. I review the ticket when it's sent to me as soon as I see it to determine if I need to make myself available straight away or not. If I don't and it's for something minor, I often leave it open for some time, because these tickets already have estimated dates on them and I still get back to the client within that time, however in doing so at least 50% of these tickets resolve themselves or the client forgot they even logged one in the first place.
If it was more urgent than it seemed at first, the cilent will chase up and then I will get back to them straight away.
You say my time is not more valuable than there's, but my time at the role is purely on helping others, so responding to someone straight away or not has nothing to do with me deciding if my time is more valuable than there's, it's me deciding which client deserves my attention the most at this moment.
There is no 'my' time when I working in a support job because all my time is already on helping others.
Agreed- I worked in IT for 4 years, and the biggest takeaway for me was learning how to "placate" requesters while reprioritizing issues: there is a balance between a cold shoulder, and outright hand-holding.
I find initially responding something like, "Hi ___, thanks for reporting this. I'm taking a look at this first thing tomorrow. Can you let me know when you first noticed this happening, and anything you've tried so far?" It takes 30 seconds to respond with something like this, but it saves hours of time later, and usually issue resolves itself. Soft skills in IT go a long way.
I think following a process to triage and resolve issues within expected timeframes is different than just not responding at all. In these examples hopefully somebody already responded to the client and set expectations, right?
A product support team is one of the most important sales engines for a business. If clients rave about your support, they will sell your product for you. Hard to do that if the attitude and approach is "do nothing" and wait for issues to hopefully resolve themselves.
This! It's totally true that being anxious to please can be wasteful and long term harmful, but there is a long way between that and "do nothing". Here are some scaled responses to low-value requests:
- Nudge for a better request. Create and refer to a standard for making requests that helps people get past their psychology and into substance before seeking help.
- Ask for impact assessment. It is fair for people to seek help before attempting to resolve a problem if the scale is large enough, but it's important you get info that helps you prioritize. Ask for it.
- Set expectations. Being honest about where helping fits into your priority queue lets the other person plan accordingly, and gives you a way to be responsive without constantly switching gears.
The main reason not to do any of the above is to obfuscate your own process, which is long term harmful to your team relations. On the other hand, when dealing with competitors, unwanted services, etc, "do nothing" is an underused strategy...
The problem is that most of that is work, sometimes considerable work. However sometimes interruptions are impossible to avoid, and also you need to do some of that work anyway.
Generally you want at least the following two tools to handle it:
"interrupt shield" mechanism - it involves having a set time for answering interruptions, and if you have more than one person on the team, having them cover different time frames as the point of contact person.
Setting expectations about time frames for reaction etc and enforcing them. Which means not just making sure you answer on time, but also to ensure you don't unnecessarily overcommit. Do not create an expectation of jumping to it.
I've been in ops last two years, and few things will kill us more than somebody not following up on a raised issue.
Now, in responding to a raised issue, absolutely: look at priority, big picture, context; maybe point them to a more appropriate resource or person.
But look at time stamps - unspoken part of this equation is:
1. Could you have helped this person resolve this issue by 12:17 by providing them a simple answer, instead of letting them struggle to find answer (likely through somebody else who bothered to respond) by 12:28?
2. What if EVERYbody took your approach - would they still have resolved the issue by 12:28?
I think they have found an approach that works for THEMselves, and are completely ignoring what's best for the system/project/team. As the op said - this is what perpetuates stereotypes of IT.
I know this kind of colleague unfortunately. Actually there are a couple of different types that express themselves in the way the article shows (or slight variations of).
One type is the one that just never gets it. They really have no idea how to do their job but they know how to work other people to do their job for them. As long as _someone_ responds to them this will continue. If _everybody_ stopped responding to them, someone in charge might actually get a clue and just get rid of them, because their "output" would go near zero.
Some do this via being nice, sociable people, while others try it through intimidation. Like "I need to get X done. You need to help me, VP of XYZ needs this by EOD", basically implying that you're on the hook for their work and the VP of XYZ would see it as _your_ failure if you didn't do this guys work for him.
You often know your users. Some people need to be left to figure it out. Those users will call ever day to ask for things they can and should do themselves. For that sub group you should avoid helping at all costs.
Others, if they raise a flag it's time to drop everything and stop at nothing to fix it because you know they wouldn't be talking to you unless it's critical.
"What have you tried so far?" is a phrase I say a lot when colleagues request assistance. Those six words can be remarkably effective at focusing the requester's efforts without giving them the cold shoulder.
It depends on who is asking for help. But for many, it doesn't help them to answer too quickly:
- sometimes it's like giving the spout to a child who doesn't know how to use a spoon yet.
- sometimes it's like answering someone who could have found the answer by searching 20 seconds on Google.
Answering too quickly can make your interlocutors dependent on you.
Similarly, before asking someone for help, it is usually a good idea to spend 30 minutes looking for the solution yourself. The time lost is more than made up for later.
If your relationship with the requestor is a mentor/mentee or you are their supervisor, then sure, go ahead and let them stew a bit to see if they can figure it out.
If you are in IT support, it isn't your job to treat every colleague like a child who needs to learn. It's your job to serve others and remove any IT-related barriers to their productivity.
When I was doing IT support, half the requests were things people could figure out themselves if I just waited. But I was there to make their job easier and make them feel supported. Making them wait doesn't make them feel supported or instill confidence. Knowing they could call or text and have an immediate response is a huge boost to their productivity and feeling of confidence vs. wondering if or when I might reply.
> If you are in IT support, it isn't your job to treat every colleague like a child who needs to learn. It's your job to serve others and remove any IT-related barriers to their productivity.
No, it isn't. If you do so, clients will start calling you even for minor issue that they can solve themself, just because it's more easy to have you do that, or it's faster, or they simply doesn't want to learn to do new things.
> Knowing they could call or text and have an immediate response is a huge boost to their productivity
To their productivity I don't completely agree, because they don't learn to solve the problem in case it happens again, to your productivity surely not, maybe you are busy doing something, and they keep calling you for trivial things that they can figure out themself.
I think we're conflating two different things. "Do nothing" in the example given was to basically ignore the person and hope they figure it out.
Responding quickly and being available doesn't mean you don't also teach. When I did desktop support years ago I always explained what I was doing and why. Your mouse isn't working? I'll be right there. Let's see, sometimes disconnecting and reconnecting can fix. Let's try that. Yep, that worked. Oh, thanks - I'll try that myself next time!
I also found that responding quickly and having a humble/service mentality builds trust and respect. Those are the very things that give others pause and a desire to figure it out themselves because they trust you and respect your time. If you treat others poorly by ignoring them, for example, they are less likely to care if they are bugging or interrupting you.
That depends. Does your org really want to pay for IT to support everyone? Or do they want selfservice systems that only need IT when something genuinely breaks?
I'm a partner in a pretty successful services company, our success is mainly built on the prevalence of the do nothing attitude in IT departments in contrast to our 'drop no request' attitude.
This is my problem when being on the other end of "do nothing". We subcontracted our it support, this means no one in our company has direct access to systems supported by contractors. And then you need some trivial information and have to wait or ask multiple time. Compated to past when you had tools and access to get that information yourself.
This was the phrase used, around every patch tuesday, when every little hiccup on our network was blamed on patching.
It was never SCCM.
As the guy in charge of patching, I built a delay in the feedback loop to allow for the 'real issues' to present themselves before researching that, yes, for the 800th time, it wasn't SCCM.
> Doing nothing is akin to saying my time is more valuable than yours, you silly plebian. It's the sort of attitude that reinforces the unfortunate stereotype that IT people are arrogant and view their expertise and role as more important than others'.
But... It's (for developers) ! They are building things, value. That is not the case for everyone.
> I found great success providing IT support by always responding immediately when I'm available, and establishing focus times where others know I may not respond right away. An attitude of service and humility can go a long way in winning the respect and trust of your colleagues and supervisors.
Or you will be the go to person for EVERY little issues that could be solved with little effort. Been there, done that, will not be that person again.
And in either scenario, responding "bit busy, will check in 30 mins" both allows short lived transient problems to fix themselves, and lets the sender know that yes you got their message and that you can not look at it now but you are not ignoring it either.
But it can also have a different effect. If you don't reply, the requestor does not know if you even read the message, so they might try resolving the problem by themselves. However if you say "I'm busy, will check later" they know they don't need to even try, as you are going to resolve the problem for them. That's the best case. Worst case, they'll report to their manager that you're "blocking" them and they aren't able to work for the next 30 mins because of you.
As an HPC sysadmin who's helping a lot of people, I do both, selectively.
We're very helpful as a team, but this helpfulness is being abused by some people after certain point. You need to distance yourself from these people and tell them to RTFM and do their homework first.
Otherwise I can neither do my work or help anyone else.
In support, when there is technical competence disparity between the one who asks and the one who answers it is true.
But I though this was more about developer-to-developer communication where asking a question and expecting immediate answer is also a form of putting your own time ahead of the other's time.
I experience it from the other side on a couple of open source projects. I asked a question, nobody jumped in to solve it, and I had to actually read the code carefully, debug my issue and file a patch. Which kind of makes sense, because I am the most interested and informed person when it comes to my use case. Works the same way for closed communities of colleagues.
> Doing nothing is akin to saying my time is more valuable than yours…
And what if it actually is?
Technical people, in particular, are often working on improving system throughput over the long term. It can take a lot of discipline for an organization to stay focused on these goals, and unfortunately it can mean short term pain for individuals.
The other extreme is a staff that is very, very busy and yet can’t keep up with even routine upgrades and maintenance.
(This is the classic “urgent versus important” problem.)
In the context of the article, a strategy of selectively doing nothing only works, where the usual behaviour is well known to support, devs, colleagues et al. in an organisation. It is more of an exercise in how to manage expectations, mitigate frivolous attempts, seamlessly categorise and delegate requests, rather than any overall inaction.
coming from an engine mechanic here...this type of 'bury your head in the sand' malarkey is seriously acceptable for IT?? let me give you an analogy:
customer: can you check the differential too? my team driver says whenever she does a full lockout the steering wheel makes a clacking sound.
me: does nothing
customer: the clacking noise is gone nevermind.
newspaper: two dead after truck wheel shears from axle and collides with minivan.
Just because the symptom goes away, doesnt mean there isnt a problem that could require your attention. "do nothing" is a solution to your own poor attitude and disposition. in the authors example that button disappearing could be a cyber attack, could be malware, could be anything.
you are making excuses for yourself and gaslighting the requestor to avoid handling something you should either automate or investigate.
As support, you often have the knowledge to accurately determine whether a request is truly important, or can be ignored temporarily in lieu of more important issues.
A more accurate example using your particular automotive context would be a customer complaining that they don't know how to change the radio stations.
Feel free to drop everything in the middle of your engine replacement job to teach this person how to use the radio.
> Doing nothing is akin to saying my time is more valuable than yours, you silly plebian.
Well, isn't it? Just calculate how much you make per hour. Your time is more valuable than the time of anyone making less.
> It's the sort of attitude that reinforces the unfortunate stereotype that IT people are arrogant and view their expertise and role as more important than others'.
This is probably a good thing. Too often IT doesn't get the respect it deserves. Other people also view their expertise as more important than ours.
Just because a caller earns less than you means nothing. If they’re a junior clerk and they can’t enter a million dollar invoice without your help, well their time might well be more valuable than yours.
I have witnessed plenty of cases where a lower-paid employee is performing a critical function that if not resolved has phenomenal cost.
e.g any number of administrators/co-ordinators/financial officers may get "paid less" than an IT support person; but a) the IT support person is explicitly being paid to support them and b) the value of actions they make is not 100% tied to their hourly rate - processing an invoice, writing up a contract, fulfilling some SLA, whatever.
But what is the solution? Most wealth of people like Elon Musk and Jeff Bezos is tied to ownership shares in their companies. I don't think it's fair to force them to sell shares so they can cover higher taxes. I also fear efforts to extract more tax money from them will ultimately just raise the bill for the middle class. The ultra wealthy can afford to hire a team of accountants to find the loopholes while small businesses are stuck with higher corporate tax rates.
One solution- if someone is taking out personal loans that function like income, let’s tax it like income. If someone really wants to live on 80k a year, that’s fine. But if they’re reporting 80k income but spending 10M, maybe they should be paying their fair share on that.
Edit- this has the benefit of completely avoiding the issue of unrealized gains and sticks to the issue of income...
It functions like income when they treat it like an average person treats their income. Spending on their home, their car, travel, etc. They’re using the loan to avoid taking income or realizing gains.
But yeah, I would be down for a more sensible sales tax situation. I’m sure there are a hundred ways to skin this cat.
How is that any different than paying with a credit card or using reward points? Those aren't taxable or treated like income so why should loans and mortgages be?
Someone sufficiently wealthy can push off taxes until they die and their heirs can use the step up basis[1] to avoid them entirely.
There's also a huge advantage in the ability to choose when one wants to pay taxes even if they eventually do get paid. Buffet loves to talk about unrealized gains as a loan from Uncle Sam at zero percent interest.
I think this is where at least talking about rather than a wealth tax a usage tax. Now some will fall through the cracks as a billionaire that lives like a middle class person would be taxed as such but that could be viewed as fair since the assumption is at some point the wealth will be spent and taxed. The trick of a usage tax though is some kind of baseline income or offset to prevent the inevitable result of permanent poverty as rich have the safety net of wealth and a usage tax just encourages them to hoard more and distribute less to employees.
Why would they need to sell anything? Just take a salary large enough to cover the wealth taxes. A CEO with a $100M net worth should easily be able to command a salary greater than $1M.
Some are. We live in an area where annual taxes are about 2% the value of the home. Home values have been skyrocketing and taxes along with them. Some people on fixed incomes can't afford it so are forced to sell. I think property tax should be abolished in general, but the problem with taxing ownership of a company is that owners are then forced to spend that much less on expenses to cover their tax burden (fewer jobs, or lower salaries for employees).
A lot of companies operate close to break-even or even at a loss. What happens with the owner of a $2m / year company must come up with a 10% wealth tax amounting to $200k, but the company is operating at break-even? Expenses must be cut to pay the tax. Ultimately hurts the lower and middle class the most.
> I don't think it's fair to force them to sell shares so they can cover higher taxes.
If the treshold is high (say $1B) then I don’t think it would be that unfair to tax stock like property at e.g 1% a year.
Diluting power would just be a secondary benefit in megacorps.
I just don't see that working in practice. I've worked hard to build a small company and can't imagine losing 1% a year. The longer I work the less I own. If this was the reality, people would find a way around it even if it meant incorporating in another country entirely. And lets be honest, it would start at 1% and go up from there. We pay almost 2% / year of our home value in property tax.
I'm not saying to stick the middle class with the tax bill - just pointing out that taxes on the rich usually end up being paid by the middle class whether intended or not.
The better solution is to cut spending and the need for more taxes in general.
100% agree, though a good ORM handling migrations can be nice as it documents how the schema has changed. Just be sure there is no schema logic that exists only in the ORM and not at the database layer itself.
reply