ndcrandall

  Location: San Francisco Bay Area
  Remote: Open to all (Remote, in-person, hybrid)
  Willing to relocate: Yes
  Technologies: Ruby, Ruby on Rails, React, React Native, Java, Spring, MySQL, PostgreSQL, HTML/CSS, Javascript, AWS
  Résumé/CV: https://drive.google.com/file/d/1iENUTfuqwvsjW6i9LC-eDyx89h_UCYzH/view
  Email: [email protected]
  LinkedIn: https://www.linkedin.com/in/nicholas-crandall-658849a/

I'm an experienced Software Engineer and Leader with 13+ years of industry experience. Much of my experience includes being an Engineering Manager, but I'm also very hands on, mostly on the backend using Ruby on Rails and Java. I have a lot of experience integrating and scaling 3rd party APIs into backend systems.

I come with a lot of domain expertise in CRM, specifically integrating with Salesforce. I'm willing to explore new domains as well.

I'm looking for interesting engineering roles or leadership positions. I'm flexible with in person and remote roles.

  Location: San Francisco Bay Area
  Remote: Open to all (Remote, in-person, hybrid)
  Willing to relocate: Yes
  Technologies: Ruby, Ruby on Rails, React, React Native, Java, Spring, MySQL, PostgreSQL, HTML/CSS, Javascript, AWS
  Résumé/CV: https://drive.google.com/file/d/1iENUTfuqwvsjW6i9LC-eDyx89h_UCYzH/view
  Email: [email protected]
  LinkedIn: https://www.linkedin.com/in/nicholas-crandall-658849a/

Experienced Software Engineer and Leader with 13+ years of industry experience. Much of my experience includes being an Engineering Manager, but I'm also very hands on, mostly on the backend using Ruby on Rails and Java.

I have a lot of experience integrating and scaling 3rd party APIs into backend systems.

I'm looking for interesting engineering roles or leadership positions. I'm flexible with in person and remote roles.

  Location: San Francisco Bay Area
  Remote: Open to all (Remote, in-person, hybrid)
  Willing to relocate: Yes
  Technologies: Ruby, Ruby on Rails, React, React Native, Java, Spring, MySQL, PostgreSQL, HTML/CSS, Javascript, AWS
  Résumé/CV: https://drive.google.com/file/d/1iENUTfuqwvsjW6i9LC-eDyx89h_UCYzH/view
  Email: [email protected]
  LinkedIn: https://www.linkedin.com/in/nicholas-crandall-658849a/

Experienced Software Engineer and Leader with 13+ years of industry experience. Much of my experience includes being an Engineering Manager, but I'm also very hands on, mostly on the backend using Ruby on Rails and Java.

I'm looking for engineering or leadership positions. I'm flexible with in person and remote roles.

This was one of my biggest issues, even as an experienced developer with a CS degree. I always felt a step behind since I wasn't fluent in the latest and greatest framework. All of that changed when I mentally decided to focus on one language, namely Ruby. It's amazing how much you can do with any one language even though it's not fully optimized for a specific use case you need.

I can honestly say this was the biggest pain for me as a contractor. I decided to go without health insurance and paid the fine for not paying quarterly taxes just because I didn't want to deal with the hassle.

Even though this is a free tool, I would have gladly paid for it to help alleviate those issues.

So after going back and forth with our startup on SOA or not, I have felt like separating these services out of (in our case) a monolithic Rails application has made sense. I would like to use Sinatra for one service, rails for the web interface, and possibly Python for the last service. I understand this adds a lot of overhead by creating an interface and authentication for each service.

For me the logical division of services seems to make sense especially when using 'the right tool for the right job'

I may be over optimizing, but I think it will pay off at a later date with more developers and the need to scale each service separately. Maybe someone can point out issues with this thinking (besides those addressed in the blog post).

Just a hint shift+scroll wheel in a lot of cases will scroll horizontally.

The usual advice applies, if you are really worried consult a lawyer. Many will do 30min - 1hr consultations for free and will enlighten you to the risks about your app specifically.

An LLC will protect you from most liabilities and is probably the easiest way to protect yourself in this case. Worst case scenario they sue the company and get all $0 worth of assets from it (assuming no sales).

Applying for an LLC is fairly simple and straight forward. Most states allow you to create one online for less than $100. It honestly takes less than an hour to set them up. Beware the tax implications of doing so, it's a pass-through entity meaning profits and losses are passed directly to your personal income. This is usually not a big deal and most tax software makes this very simple to document at tax time, just keep a record of all profits and expenses.

This is just from experience so take it with a grain of salt. Hopefully this gets you started with some further research.

I overlooked the license that would be created for hosting the source internally. That seems like a good route. I also agree that most enterprise clients wouldn't be interested in stealing the source.

It may just be a legal issue, along with a manual process of checking out the code and installing it on a VM they setup.

The main differences between being an individual vs a company are the intentions for which a client hires you.

Being 'Designer John Smith' attracts companies hoping to lure you in as a full time employee eventually. This can be good for finding work when you don't decline the possibility of full time work, but can burn bridges when you decide to leave the client.

Being 'John Smith Design Studio' attracts clients looking to offload development to another company in order to meet deadlines and get stuff done.

I left work in a way that I believe is less cold turkey and helped ease the transition. Instead of quitting, I told my supervisor that I would like to work as a contractor. My reason for doing so was to live elsewhere and be more flexible with my schedule.

Since I was so valuable to the company at the time, they were just happy I wasn't quitting. After a few months of contracting I told them I was done and by then I had other opportunities come my way. It worked out very well.