Just a reminder, services like Google Photos are not a backup.

Want to lose nearly three years of photos?
Use Google Photos and do not keep offline back ups of your photos / Takeout archives.

Bootcamps get you up and running in coding quickly. If you are a programmer, companies are only interested on how quickly, error free and cheaply you produce marketable output. Bootcamps enable this.

More or less you are not more than a former assembly line worker putting parts on a car platform. Your value is not very high as you may be exchanged at any time at their will.

Nevertheless, you can earn money quickly. You trade in your youth and time which might be a dead end in the long-term. Trends go to machine learning, artificial intelligence. They will not need Bootcamp people and code workers.

It is better you set up Bootcamps and sell them versus absolving this. Like selling shovels during the gold rush, but not working in the mud of Alaska by yourself.

Your choice is: Making quick money, which fades anyway; or striving for the long-term future proof career.

C/S degrees from Technical Universities of reputation give to you the right direction under a strategic consideration. Companies which pay well, or freelancing with a solid acknowledged background, will always look for top graduates. People from Bootcamps are just OK for hammering assembly line coding. Even worse with SCRUM in one noisy room under enormous team server pressure controls, counting your lines of code per minute, with pale people all around. And groups of controllers never acknowledging nor trusting your work.

To acquire a serious degree, a Bachelor is nothing. Here, in INDIA, Bachelor now is what a former high school grade was. You must carry a diploma or Masters degree combined with internships at big companies with high brand recognition. This will require 4–6 years of your lifetime. You can support this financially by working part-time freelancing as making some projects front- or back-end web, data analysis and else.

Bootcamp people will lose in the long-term. They are the modern cannon fudder of software production.

It is your choice. Personally, I would never do Bootcamps. Quality and sustainability require time, deep studies and devotion.

What do you get distracted from?

Unpaid internships are the worst thing. You exploit young people and promise them experience. Seriously business makes tons of money yet they come with ways to exploit a young person in IT. I think it is evil.

some miserable life...

me vs vmware this week

TL;DR :

"when i die i want my group project members to lower me into my grave so they can let me down one last time"

STORY TIME

Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.

As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.

The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.

Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.

It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.

Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.

Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).

The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.

So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.

Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.

So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.

We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.

Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.

git commit -m “it compiled”
git commit -m “typo”
git commit -m “ugh”
git commit -m “wtf”
git commit -m “ok this doesn’t totally suck”
git commit -m “:shipit:”

Yet another commercial seminar upset I won't give up a day of my time to fly to the UK to speak at the event for no payment or reimbursement for my travel.

But of course I should think about the exposure and networking opportunities! 😕

I've got at least 4 hours of homework... Now THIS bullshit!!

Is it just me or is the 'storefront' test for CAPTCHA much harder than the schoolbus or traffic light? Could be my diminishing eyesight, or bourbon too.