f1gm3nt

https://github.com/JoshuaEstes/CheatSheets was used to help me learn different shortcut keys for different programs and apps (tmux, vim, mutt, git, etc.). It's just a collection of what I found useful or found myself always looking up the same stuff. Now it's mostly used as a reference from time to time.

Because the CTO only does the code reviews, people create the PR and the CRF. Issue is because it takes so long, the CTO wants merge conflicts resolved before it's reviewed. Problem with that is, no one remembers the context a month (or longer later).

I have A LOT of spare time so I will often help out with doing reviews but because I'm not allowed to merge or deploy code, it's more of helping junior engineers write better code.

Remote: Depends

Willing to relocate: No

Technologies: PHP, AWS, terraform, SDLC, agile, way too much to put here

Résumé/CV: https://github.com/JoshuaEstes

Email: joshua.estes@pm.me

I've had various mgmt roles as well as coding roles. I like doing both but prefer to only do one at a time. My career has mostly been PHP and eCommerce related. Have done a lot of marketing automation stuff as well.

Also, it’s about priorities and goals of the company. Security and control is the main reasons I see companies migrate to data centers. Generally things like GitHub Enterprise are being used.

Another thing to consider, as a developer, is how to make your app as independent from vendor requirements. For example, if you build an app in such a way that it only works using SQS you’ll run into issues down the road.

Also, why y’all using dedicated dev VMs? IMHO it sounds like there are other issues to solve before you migrate the app somewhere else. If I was in your position I would work on making the app easier to setup and deploy. Your CTO has a lot to consider and being a CTO at a startup isn’t an easy thing. How long does it take to deliver a feature to customers? How can you help speed that up? What are the engineering goals of the CTO and how can you help with those goals? Make his or her life easier and work with them. Continuing to push an issue like this will cause you frustration and make your CTO dismissive of your ideas and suggestions in the future.

I also don’t have a college degree but have the experience to back me up. I’ve noticed at organizations where they hire fresh out of college or bootcamps is just a bunch of people that would rather talk computer science than write code that can be read in the future.

The best companies are hard to find gems that look like shit from the outside. For example, one company I worked for would dispute every Glassdoor review that wasn’t a 5 star saying it was a disgruntled former employee. It was a highly toxic company with amazing reviews on Glassdoor. Compare that with the company I’m at today that has just over a 3 stars.

The best companies that aren’t complete shit will empower you and encourage you to be your best. They understand they hire for your expertise and get the fuck out of your way. They demand results and also realize that results can take time. Not many people are able to work in this type of environment. You’re essentially looking for a company who treats employees like a team. Just like any professional sports team, the worst players are cut. However, the company also understands balance and sees excessive working as a problem. You’re looking for a company where the one doing the hiring is looking for someone smarter than they are.

In my opinion, the best way would be to read the reviews, and I mean really read the reviews you find online. Why are people saying what they say? Are they new hire reviews? Research the executive team and anyone else you can find at the company on LinkedIn. Before you go to any interview do research on the company and come prepared with questions you want answered based on your findings. Ask the company why you should work for them without being direct. Try talking to others who work there and get a feel for their personalities. If you smoke, go find where the smokers are and start conversations with them. If you get an offer, negotiate a contact for 90 days. During those 90 days, you want to keep interviewing the company. How’s the onboarding? Are they setting you up for success? Is there politics? Are there any assholes? Look for any red flags. There might be warning flags but the point is, you both are testing each other out.

Every company will have its pros and cons. I’ve decided to work at smaller companies which pay a little less but I have more opportunities to learn and grow vs a larger company where I’m a one trick pony.

When I’m hiring for positions I cross out the school or bootcamp “education”. My top priority is to see what you’ve done in the past and what you’re passionate about. If I like a resume I want a code sample, most have their GitHub in it. I review the code and see how well it’s formatted and how it’s organized. It takes awhile, but I think it’s worth it.

So, keep at it, do some small projects on GitHub you’re proud of. Bonus if you can find a project and contribute to it, even documentation counts in my book. Mentors are also helpful.

You got this!

But I guess that’s your point?

The startup that I joined after that had passwords stored in plaintext via a google spreadsheet. Code was not stored in VCS and updates were done in production. I helped the organization adopt scrum and added some development processes in place and added tools to help me and the small team (me +2) of developers manage the different codebases a little better. No one wanted to do this but I forced it anyway.

The organization I'm at right now was similar but has a lot of different challenges.

Each organization you join will be different, the culture will be different. Some will be focused on quality and some will not. You need to understand a few things and be able to communicate with executives and/or managers to accomplish your goals.

Executives do NOT GIVE A SHIT about automated deployments, code coverage, code reviews, etc. They view those things as wastes of time and the "code monkeys" should just get back to work. I'm not saying this is the case 100% of the time, but you need to change how you communicate with these people. Explain what tech debt is and how small investments in time can reduce this. Yes, going from 0% code coverage to 80% is going to take time, and this is something you will need to explain to them.

Some devs are similar and I think that's mostly because no one sticks around long enough at a company to maintain their shit code.

Depending on your role you are either in a position to force these things to happen or you are in a position where you need to bring others up to your level. Both are difficult in their own ways and will require a large time investment on your part. However, BOTH will require you to help others raise their expectations.

The other thing I want to leave you with is a conversation I had with a mentor a long time. Being in a similar situation he told me to not hold others to MY expectations. Hold others to THEIR expectations. This comes back to helping others improve. Bring others UP to your level.

If none of this helps, you may want to quit and find another position elsewhere, but keep in mind, this will be something you are going to run into in many organizations and you are going to have to learn to deal with it.

Once I’ve skimmed it I pretty much have a good idea of the outline and where the material is at within the book. After that I just read the parts I need most and implement them into a project.

I will often times go back and read things again an reimplement until I’m happy I understand most of it.

It might not be the best way but it’s worked for me and has helped me implement new things in a short amount of time.

Also becoming obsessed helps.

You can also see http://www.shmoop.com/atlas-shrugged/dollar-signs-symbol.htm... which discuesses this.

"The dollar sign? [It stands] for a great deal. It stands on the vest of every fat, piglike figure in every cartoon, for the purpose of denoting a crook.... It stands – as the money of a free country – for achievement, for success, for ability, for man's creative power – and, precisely for these reasons, it is used as a brand of infamy....It stands for the United States."

A book I revisit every few years. It's taught me to be honest with myself even if the social norms aren't in alignment with I'm doing.

It's also gave me a deeper understanding of my fellow man and why some are fine with handouts from others.

It's also where I learned the $ symbol is made from the U and S from United States.

The company I'm at now is using LastPass shares (which the creds can easily be obtained as others here have mentioned) and for a lot of other services there is a default username and password based on your name.

I'm trying to change the security culture at my current company, but it's hard since a lot of "security" is more of a pain in the ass. Example, "Why do I need to put in this code if I already put in my username and password?"

Your point is that this is required, it's not. Using annotations is optional. The user you point to in the example wanted to use the annotations and wanted to use php templates.

The FACT is that in Symfony2, your Action MUST return a Response object. Using annotations is an easy way to get around this.

> Yes, there are other BETTER ways to do it. Making comment-based annotations available as one of the ways pretty much guarantees that people will use it, and that seems like a bad idea to me. Just remove them so no one is able to choose the bad practice.

Why is this a bad practice? Everything I need to now is right there in the annotation. I know that it's a string, integer, or anything else. I don't need to open up another file to check.

> Uhh, OK? How about comment folding in text editors? Would you, as a developer, be happy if you encountered some code that made heavy use of annotations for critical application logic? I wouldn't--this is what I mean by DX.

... You can't unfold them? You mean to tell me that having an editor that folds comments is bad design for the software that uses annotations? I'm trying to figure out this critical application logic you speak of. If I'm using annotations to describe a column that is a "string" type and has a length of "32" then what is the difference of it's in a yml or xml file? I enjoy being able to tell that as well as what relationships there are.

> The same thing you gain by var_dump()ing any variable--an understand of what's happening under the hood.

Again, why are you trying to var_dump something that has no value in using a var_dump on? An example of using var_dump and it being useful is "var_dump($user->getSomeRandomCrap())". It tells me what is returned by that method. Is an object or something else returned. WHY DO NEED to var_dump "@Column(type="string", length=32)"? I know the property should be a string and should be a max of 32 characters long?

First off, this is completely false. With symfony2 the action needs to return a Response object. This annotation isn't required and the team I work with, we rarely use this.

It's very useful for when you are just adding a page that contains no real business logic.

"Doctrine 2 does the same thing when declaring object properties based on database table columns1:"

Oh look, there's a footnote.

"Fortunately, Doctrine also allows you to declare property metadata using PHP, YAML, or XML"

What?

"Because code comments should never be necessary for a script to function properly"

So your points are that we need @Template annotation to be able to render a template, which is FALSE, and you state the same with with Doctrine2 which you point out there are other ways to do it.

All your points for "DX Regressions" are completely wrong.

Unless I am using a special plugin with my IDE it's not going to link "AcmeBlogBundle:Post" to src/Acme/BlogBundle/Entity/Post.php. Most of what you point out is complete bullshit. What do I gain to hope by using var_dump() on an annotation? I know that in a Doctrine Entity that the column type is a string.

Articles and posts like this drive me banana's with the complete lack of understanding what you're writing about.