I've got three things. The last is the key in a "I know more now" sense but the first two provide the framework to let you go ahead and do it or hold you back.
Confidence. You are only as good as you let yourself be. Believe in yourself more. Don't let your worries block your development.
Forgiveness. Forgive yourself for mistakes and not knowing things. As that DHH viral Twitter thing showed, even the best and most productive developers Google the basics all the time
Challenges. I grew the most as a developer when I had to do something and I needed to get something done. Be it a side project, new job or saying yes to something a little out of your comfort zone, challenges help you forge ahead with purpose.
It's often why books and courses don't get you that further ahead on their own. It takes that need to fix x or implement y to really develop
It used to have a minimal set of things you could install but moved to a clean Ubuntu box that you can pretty much muck about with and install what you like.
For Rails, it is perfectly suited and very easy to spin up an Ubuntu VM and play.
I used Cloud9 before hand and though this was a while ago, I had a demo of an Express thing with MongoDB and about 15 mins before said demo it started falling apart.
I believe the uptime is pretty great, just a lasting impression of failing just at the wrong time.
Codio seems to have pivoted however to be more about offering educational institutions the ability to create courses etc. so though powerful, that is what the developers are focused on now
Occasionally the version number of things lag behind in Codio and that is my biggest gripe. That and PHP boxes not having mod_rewrite enabled out the box, but that is just me
I work in a large health organisation right now and the thing that seems to blow most away is just saying yes.
I don't work in the IT department and they basically say no to everything. Regardless of business value or difficulty.
I work in the chief executive office and numerous departments will be amazed when I say yes... Let me look into that.
Recent example was a publicly facing, real-time waiting time tracker for the city's A&E (as well as two walk in centres). Each solution I thought of had compromises but they chose the one they could live with.
Healthcare IT is one of the most backwards areas of IT to work in, I think, in large part because of the legal red tape around everything clinical. So you get a lot of people that say no automatically.
Additionally, I think you get a lot of people that don't really have an "IT mindset." I don't know about where you work but in my neck of the woods we have so many people in programmer positions that can't even write a three line script. They're great at clinical stuff because they came from there (e.g. nursing) but have no technical background...
I have a different theory: For many IT applications you can tell users to conform to the system's needs or take a hike. With healthcare (and some other government type services) you don't get that option.
If I'm Amazon and you don't have a computer? Sorry, come back when you do. No e-mail address? Sorry, come back when you have one. No credit/debit card? Sorry, come back when you have one. Don't know your postal address? Sorry, come back when you know it. No phone that can get SMSes? Sorry, come back when you've got one. Don't speak any of the languages we use? Sorry, come back when you do. Unable to pass a captcha? Sorry, come back when you can. Bad at reading and can't navigate our site? Sorry, come back when you can. Blind and your screen reader doesn't work with our site? Sorry, come back when you have a different one. Child that doesn't know their own name? Sorry, come back with a grown-up. No address because you're homeless? Sorry, come back when you've got an address.
Companies that can decline service for such people can make many simplifying, cost-saving assumptions in their IT systems.
If you can't decline service (Hospital, voting etc) you need to deal with such corner cases - and combinations of several. I can understand how getting that right would raise costs substantially.
Lots of good advice here about pushing back. Be sure to do it in your own voice of course and no need for a revolution. It may be best to focus on small things and grow from there
In that vein, the BBC used to vet new hires (in an assessment) around how they would react to a colleague who kept asking for help on similar things but refused to learn how to do it themselves.
No idea if they still do this but worth thinking if you are enabling your colleagues to just dump it on you.
Ask yourself, do you completely take over? Have you tried getting them to do it by talking them through but not hands on solving it for them?
Often quicker a couple of times to just take over but long term they'll be reliant on you and you'll be stuck helping them solve that problem time after time.
Harder to do that with tasks from a manager or similar, but I've found it helps to talk through what you'd have to do, what you'd have to drop and problems you see coming. You'll probably still have to do it but you can make explicit what will move down your pecking order.
Wish you and the team at Brightwork well Josh. Good luck on the launch.
Don't want to be negative but I will say the landing page wasn't as polished as expected. So important in terms of confidence especially as I'd be paying you to own lots of my apps' back end. Case in point is the use of images with text in them rather than an image with text underneath.
As someone who has to build things solo most of the time, AWS does not need a specialist.
Oh yes, to squeeze the most out of it, I am sure it does.
But you can get along with EC2, Route 53 etc. pretty fine.
Personally found the multiple terms, docs (outdated) and other stories of people being billed lots pretty intimidating but when it came down to it, it wasn't as scary as I made it out to be and I've set things up at about half the cost of Digital Ocean and others.
Noise cancelling headphones is something a lot of people use.
Angle your desk/screen away from other people's eyelines or things that distract you. One place I worked I was right in front of the kitchen area and that was very distracting. I moved towards a window and that was better because the seagulls didn't tend to distract me.
Another thing I love is a standing desk. I can work in my busy kitchen at home and grab enough focus while a million things are buzzing standing up at a laptop. Don't know when, but realized that and now I prefer to have a dual standing/non-standing desk in open offices as well.
Naturally, that can be a bit awkward in an open space so you have to make sure you're not then distracting everyone else.
Confidence. You are only as good as you let yourself be. Believe in yourself more. Don't let your worries block your development.
Forgiveness. Forgive yourself for mistakes and not knowing things. As that DHH viral Twitter thing showed, even the best and most productive developers Google the basics all the time
Challenges. I grew the most as a developer when I had to do something and I needed to get something done. Be it a side project, new job or saying yes to something a little out of your comfort zone, challenges help you forge ahead with purpose.
It's often why books and courses don't get you that further ahead on their own. It takes that need to fix x or implement y to really develop