If you're interested in working with cool tech like blockchain and AI, but are tired of startup culture, a good option might be one of the "Digital Innovation Lab" organizations that more traditional companies are putting together. I just started working for one, and it's pretty great - I have stability, sane hours, solid compensation, and a healthy culture, but I also get to work with a bunch of really smart people on cool technologies.

Interesting, I am currently in the process of setting one up here in Singapore. Could you give me more information about staffing (FTE devs, PM's, Mentor's, etc). How long is the process from Ideation to Innovation Lab?

I joined the lab after it had been up and running for about 6 months, so I'm not sure what setting one up looks like.

However, I can tell you that probably the most important thing we had going for us in terms of getting of the ground is my boss, our VP of Innovation. He's been with the company for a many years, and is generally very well regarded. He also works tirelessly to promote the lab and get the rest of the company involved.

We also have an HR manager, herself a long time company woman, and that's been essential for recruiting talented engineers and inters, as well as helping guys like me with the transition from startup land to an old school corporation.

Other than that, we're all full time engineers, plus interns from the local university, especially in the summer.

Where do you work?

> such as closing JIRA tickets

I'm not a big fan of JIRA myself, but even cool startups need to use an issue tracker?

No, cool startups don't have any code issues, so there's nothing to track.

>> # Elixir + Phoenix is the future -- Python/Ruby/Java are too mainstream for us

>> vi main.ex

>> # No tests needed thanks to BEAM ;)

>> git add -A

>> # No need for descriptive commit messages; we spend our time on the important stuff ;)

>> git commit -m 'New commit'

>> # Rockstars push straight to production

>> git push origin master

Am I doing this right?? /s

Don't forget to git push --force to resolve conflicts!

We have a company taser for people who do this.

You have to self-tase one second for every commmit you blew away.

Top score is 4 seconds.

I'm not a fan of complicated git flows, but are there really people who force push to resolve conflicts? I mean professional developers who do this on real projects?

Nothing wrong with doing that on a feature branch after rebasing, as long as you are sure no-one else has pushed any changes to that branch in the meantime. Although personally i prefer --force-with-lease, which will warn you if that's happened.

If anybody pulled in the meantime and they don't know you are forced pushing they also might get in trouble because of your force push.

If you have conflicts on a feature branch I guess you aren't the only one working on it and as soon as that's the case force pushing is generally a bad idea unless you coordinate carefully with the test of the team.

The only time I ever force push is on a feature branch that only I work on and I want to amend the commit I just pushed a second ago.

I hesitate to call folks who do this "professional", but yes. I have also worked around people who blindly resolve all conflicts with their version and then comment out the failing tests.

your company is a frat house?

Don't work => don't self-tase.

I am not convinced. Instead, you'd need a reward for every cleanly committed line of code.

Also next time you need to deploy you can just use --amend to avoid having to think of new commit messages

I do it when I push to staging on Heroku :)

As an elixir dev the "no test needed" hurt. As someone that had to deal with explaining why VCS is important it burns.

But elixir does not have main file so it is ok :p

I don't think this is entirely accurate. Yes, enterprise coding can be really boring and mundane, but just as often it can be interesting and challenging and involve new technologies. As an entry level programmer, sure, you'll do Jira tickets and HTML fixes, but once you get just a touch of seniority, depending on the organization, you can get some neat opportunities.

Lots of enterprise coders are tasked with evaluating new technology, working on greenfields experiments, like building a Hadoop cluster or starting out an OpenStack test deployment. Other times, there are extremely specialized jobs in enterprises. I have some friends who write Erlang in enterprises, and they go home at 5, don't find the work too stressful, and have plenty of interesting problems to solve.

Yes, there's a lot of great tech to play with out there. You can do that on your own time as much as you can do that at an enterprise. Yeah, startups might be more inclined to work with this stuff, but they're also just as inclined to make a big tech mistake and end up 1 year down the wrong road.

Finally, I am not a fan of bootcamps to learn to code. I think they're fine to get you started, but I doubt you can actually make a real career out of just a boot camp. You'll need experience and a lot more real-world time to learn how things work when you're developing software with a dozen other people at the same time. It's a lot more complicated than just knowing how to write functions and use git.

Everyone I know who did a coding bootcamp and got a job, got a job doing the absolute most basic stuff imaginable: bug reports, bug fixes, testing, etc. There's a lot of stuff you won't learn at the bootcamp that needs to be done in an enterprise: compliance and governance work, requirements gathering, documentation development, CI/CD concerns, how to build and tweak a delivery pipeline, deployment stuff, provisioning stuff. There's a ton to learn in enterprise software development, and learning how to whip out a program in Ruby or JavaScript won't adequately prepare you. It may get your foot in the door, but expect another 2 years of working there before you'll be truly ready for a promotion or better job.

And, yes, ageism is a thing, but the absolute best programmers in the world tend to be over 50. They may not know JavaScript, but they can write an entire OS in assembly, and they tend to understand the hardware/software stack down to the bit. Old coders are absolutely incredible and wise. Anyone who is ageist in the valley against coders is really fucking themselves over.

I think the best bet for you is to do the coding boot camp, then go back to being a PM. Knowing how to actually write software is probably the most valuable skill a software dev PM can have: it'll make it a lot easier to understand why everything takes so damn long. It'll also make you much more appealing to a Google or a Facebook.

I'm going to disagree with the bootcamp grads don't do interesting work. My company employees a couple bootcamp grads including myself. All of them work on what are considered the most critical teams in our company. I work on search, which has some of the best engineers in our company. I will be working on elastic search, building our first angular 2 app, and I might even get a little exposure to machine learning / nlp.

I also extremely disagree with the do a bootcamp and then go back to a pm. You will have wasted a lot of money and will definitely not absorb much. We have bootcamp grads who have done that and they forget everything they learned. You need at least a year of professional experience to really get any meaningful knowledge. Not recommended.

I was a lifelong hobbyist programmer that went to a (well-regarded) bootcamp for reasons that only really make sense to me. I do a lot of the mission-critical work for my team/company. I've been solo dev on big ETL projects that my company depended on -- they don't teach you that kind of stuff in bootcamps, but some do give you enough database experience to figure it out.