Forem: Jeff Pereira

Change is Constant: An Examination of Changing Languages

Jeff Pereira — Mon, 22 Jul 2019 17:18:41 +0000

The Beginning of the End

Early in my career a coworker of mine told me, "Nobody likes to have their baby called ugly." I never really understood what that meant until I was working for a large company and the product that I was working on was set to be sunset. It was being replaced with a new product, which of course, out of spite I hated. I felt like all of the hours, the years even, that I worked on this product were wasted. The beautiful app I had created was no longer going to serve a purpose. It was on software death-row and I was upset about it to say the least.

Change is Constant

During this whole process of the product that I was working on being sunset I had the VP of Engineering pulled me aside and had a very profound conversation with me. He gave me a short piece of advice that I think changed my life, he said "Only one thing is ever certain, change is constant." Let's think about that for a second. It is a 100% true statement. No matter where we are in our careers, what we build, what we work on, we can always be certain that something will change. Whether it is upgrading a piece of software, or changing libraries for some arbitrary thing your app does, change is constant. Bugs will be found and need to be solved. New customer requests will come in and need to be produced as a feature. New products come along that might be that one step ahead of yours that mattered, and all of these things evoke a change in something that impacts how you work.

Changing Languages: Ruby to JS

During this process I went from a Ruby on Rails dev with about 5 years of experience to being a JS dev with maybe 1 year of experience with slightly questionable relevance. When the idea of this first hit me, I was scared and concerned. I am dropping down the totem pole by going to this new language. I am not going to know what I am doing. My career is going to suffer because of this "change" (pun intended).

Well, I was completely wrong. At the core of what we do as developers, engineers, programmers, whatever noun you want to use, we figure shit out. We are paid solid sums of money to figure problems out. Those problems to not end behind the keyboard. We have complex problems to solve outside of the software itself.

The way to change languages with the most finesse is to fully immerse yourself in it. Use the technique which allows you to learn the best. If you are an audible learner, listen to a podcast. If you are a visual learner, pick up some courses that are on sale at Udemy. If you learn by reading, grab a book. If you are a person that learns by doing, do some combination of the three, get behind that keyboard and start pounding out that code.

Syntax is merely a tool that allows us to express and utilize that big engineering brain that we have. If you are a talented engineer the syntax should not stop you from writing elegant and effective code, it should only impact the velocity at which you write it. That velocity can also be aided in the action of fully committing to the language. Over a period of time that will likely be much shorter than you think, that syntax will become second nature and you will thrive just like you did before. As far as a timeline, I would say typically within 30 - 90 days, you should be able to write some decent code. At 6 months some pretty great code, and at 1 year you will most likely be at the point where you were in your previous language. Mileage and time may vary from person to person, but I think those time ranges are a decent indication.

As a rule of thumb, unless moving to some archaic dead language, embrace the move. At the very least it is another thing you can put on your resumé and a notch in your belt of experience. While the transition will be a little bit bumpy, you will come out of it a better person and engineer.

Strategies for Accepting Change

Be Optimistic

Rather than focusing on the negative nature of the change,I was super guilty of this at first, accept the new adventure and chance to learn. Every change will run through its course and typically end up making you a better person/engineer.

Be Humble

When coming into anything new, remain humble and take the learn first approach. Use all of the resources you can gather to help you with the transitions. This includes any learning materials, courses, groups, coworkers or friends. Odds are that if you are an engineer with some time under your belt and have willingness to meet others, you will know someone that has delved into your new things. Utilize those things as tools to help you transition and lower the learning curve ahead.

Be Confident

Take the change head on. Be confident in your abilities as an engineer and put a new skill to the test. The ability to adapt is one of the most important skills an engineer can have. Managers and their superiors look greatly into this trait, and it is one of the key things that they look for when determining whether you're ready to go into your next level of engineering or maybe even into management.

Conclusion

Change exists in every aspect of our lives. It is how we adapt that makes us great and notable. The act of adapting makes us stronger. If you can, comment below on any changes whether in respect to changing language or something else at work has affected you please do.

Testing Form Reset with Enzyme

Jeff Pereira — Mon, 01 Jul 2019 14:01:46 +0000

Introduction

Being a relatively new developer to Javascript, I see everything I work on as an opportunity to learn. On the current app that I work on, test coverage needs some significant improvement, and there is a push to not only have as close to 100% test coverage on new features, but to add tests for any code you touch as a bigger initiate to increase the test coverage of the app. This initiative has really made me interested in writing tests, so my next two posts are going to be on this subject.

The Problem

Recently I was tasked with creating a new form. This is a simple Redux form with one field. All of the other data needing to be sent is masked and just sent as part of the API request. So the form only has a "Name" field, a "Cancel" button, and finally a "Submit" button.

For this entry let's just focus in on testing the "Cancel" button. The main things that I want to make sure of is that the form, which is in a modal closes, and the fact that the form resets. For example, let's say in the "Name" field you entered in "FOO" and decided to cancel and come back to that later, we should not save that input. It is a best practice in our case to clear the form for the user.

While writing tests for this form I came across an interesting issue. I was using enzyme to test the render, and it seemed like I could not find a way to test the aforementioned "Cancel" button effectively. I was able to test that the modal closed, but verifying that the field in the form was no longer filled in became a little difficult.

The Button

The button in our app creates a new thing. Let's call it "Create Foo". Once clicked it will make a modal visible that has a form inside of it. here is some sample code for the button.

class CreateFooButton extends Component {
    constructor(props) {
        super(props);
        this.state = { dialogOpen: false };
    }

    static propTypes = {
        someName: string
    }

    static defaultProps = {
        someName: ''
    }

    setDialogOpen(dialogOpen) {
        return this.setState({ dialogOpen });
    }

    render() {
        const { dialogOpen } = this.state;
        const { someName } = this.props;

        if (!someName) return null;
        return (
            <div>
                <Button
                    onClick={ () => this.setDialogOpen(true) }
                    name='button'
                    label={ I18n.t('create_foo_button') }
                />

                <Modal
                    visible={ dialogOpen }
                >
                    <CreateFooModalForm
                        setDialogOpen={ this.setDialogOpen.bind(this) }
                        someName={ someName }
                    />
                </Modal>
            </div>
        );
    }
}

The Form

In the form below we just have a simple name field. The user can then hit "Submit" which will then call the function handleSubmit which is the part that send out the magical API request with all of the data. If the user clicks the "Cancel" button, we reset the form, and close the modal.

            <StandaloneForm>
                <div styleName='container'>
                    <Confirm
                        disabled={ disabled }
                        onTouchTapPrimary={ handleSubmit(this.handleFormSubmit) }
                        onTouchTapSecondary={ () => {
                            reset();
                            setDialogOpen(false);
                        } }
                        label='save'
                    >
                        <Field
                            name={ NAME }
                        />
                    </Confirm>
                </div>
            </StandaloneForm>

The Tests

Making Sure the Modal Closes

First we want to test that the modal closes. this is something relatively trivial using some of the tools that Enzyme gives us. Below we will set up some data to render the component, and mock out the setDialogOpen function. Here we are not testing the implementation of that function as it is not necessary, we just want to make sure that the function is called. We want to make sure that filling in the form has no effect on the "Cancel" button. So we will it in, find the "Cancel" button, and then click on it.

        describe('when Cancel button is clicked', () => {
            test('should close the modal form', () => {
                const mockedSetDialogOpen = jest.fn();
                const wrapper = mount(
                    <Root>
                        <CreateFooModalForm
                            setDialogOpen={ mockedSetDialogOpen }
                            someName={ 'foo' }
                        />
                    </Root>
                );
                const input = wrapper.findWhere(
                    n => n.name() === 'Field' && n.props().name === NAME
                ).find('input');
                input.simulate('change', { target: { value: 'bar' }});
                const cancel = wrapper.findWhere(
                    n => n.name() === 'button'
                ).first();

                cancel.simulate('click');

                expect(mockedSetDialogOpen).toHaveBeenCalledWith(false);
            });

        });

Testing the Modal's Content

When testing the content inside of the modal it would be simple enough to find it with Enzyme's find, and then write a simple assertion that the content is there. This however does not work because modals are rendered in a different portal element than everything else on the page. Some modal libraries like react-modal provide some tools for testing this, but unfortunately we are not using one of those libraries. So in order to test any of the content inside of the form modal we use this bit of stubbing logic to replace our modal with a div that ports in all of the content. A bit hacky, but we could not think of a better way with the tools we have.

jest.mock('components/Modal', () => ({ children, ...rest }) => <div id='modal' data={{ ...rest }}>{ children }</div>);

Making Sure the Form Resets

Initially I thought to myself, find the button, click it and then just make sure everything looks right. One of the things I wanted to make sure of though, is that I need to fill this field in, and then make sure that the change is present.

describe('when Cancel button is clicked', () => {
            test('should clear out text from fields', () => {
                const mockedSetDialogOpen = jest.fn();
                const sidebarParams = {
                    ...a bunch of unimportant data
                };
                const wrapper = mount(
                    <Root>
                        <CreateFooModalForm
                            setDialogOpen={ mockedSetDialogOpen }
                            someName={ 'foo' }
                        />
                    </Root>
                );
                // find field and update input with value
                const field = wrapper.findWhere(
                    n => n.name() === 'Field' && n.props().name === NAME
                ).find('input').simulate('change', { target: { value: 'bar' }});

                expect(field).toHaveProp('value', 'bar');
                // find cancel button
                const cancel = wrapper.findWhere(
                    n => n.name() === 'button'
                ).first();

                cancel.simulate('click');

                expect(inputAfterReset).toHaveProp('value', '');
                expect(mockedSetDialogOpen).toHaveBeenCalledWith(false);
            });
        });

The first problem we run into here is that when we expect(field).toHaveProp('value', 'bar'); it fails. When logging the wrapper after the simulated change, the data is not present. It took me more than a few seconds to realize I need to find the field again.

describe('when Cancel button is clicked', () => {
            test('should clear out text from fields', () => {
                const mockedSetDialogOpen = jest.fn();
                const sidebarParams = {
                    ...a bunch of unimportant data
                };
                const wrapper = mount(
                    <Root>
                        <CreateFooModalForm
                            setDialogOpen={ mockedSetDialogOpen }
                            someName={ 'foo' }
                        />
                    </Root>
                );
                // find field and update input with value
                wrapper.findWhere(
                    n => n.name() === 'Field' && n.props().name === NAME
                ).find('input').simulate('change', { target: { value: 'bar' }});
                // we need to do find the field again to get the updated value
                const field = wrapper.findWhere(
                    n => n.name() === 'Field' && n.props().name === NAME
                ).find('input');
                expect(field).toHaveProp('value', 'bar');

                // find cancel button
                const cancel = wrapper.findWhere(
                    n => n.name() === 'button'
                ).first();

                cancel.simulate('click');


                expect(field).toHaveProp('value', '');
                expect(mockedSetDialogOpen).toHaveBeenCalledWith(false);
            });
        });

From here, we get a similar failure. Even though we simulate the clicking of the cancel button, the data does not change. I linked this one together a little quicker. We need to find the field yet again to get the updated value from the cancel button.

describe('when Cancel button is clicked', () => {
            test('should clear out text from fields', () => {
                const mockedSetDialogOpen = jest.fn();
                const sidebarParams = {
                    ...a bunch of unimportant data
                };
                const wrapper = mount(
                    <Root>
                        <CreateFooModalForm
                            setDialogOpen={ mockedSetDialogOpen }
                            someName={ 'foo' }
                        />
                    </Root>
                );
                // find field and update input with value
                wrapper.findWhere(
                    n => n.name() === 'Field' && n.props().name === NAME
                ).find('input').simulate('change', { target: { value: 'bar' }});
                // we need to do find the field again to get the updated value
                const inputBeforeReset = wrapper.findWhere(
                    n => n.name() === 'Field' && n.props().name === NAME
                ).find('input');
                expect(inputBeforeReset).toHaveProp('value', 'bar');
                // find cancel button
                const cancel = wrapper.findWhere(
                    n => n.name() === 'button'
                ).first();

                cancel.simulate('click');

                // find field again to that the values are updated after the reset
                const inputAfterReset = wrapper.findWhere(
                    n => n.name() === 'Field' && n.props().name === NAME
                ).find('input');

                expect(inputAfterReset).toHaveProp('value', '');
                expect(mockedSetDialogOpen).toHaveBeenCalledWith(false);
            });
        });

A Dummy's Guide to Reverting the Revert that could not be Reverted

Jeff Pereira — Thu, 06 Jun 2019 20:17:16 +0000

So I had an interesting issue come up yesterday that stemmed from a situation a couple of weeks ago. Working on a services architecture and being on the front end team, which specializes in React, you sometimes run into some hairy situations. Basically there was a combined effort to produce this certain feature, and at the very last second, the product owner decided to pull it from the release because of a bug in the back end code. Naturally the solution became, "If the UI is not there, the customer cannot use the feature." With this idea we went forward and I submitted a PR that reverted the commit where I had done the UI work for said feature.

Now let's fast forward a week or two, and product decides we need to ship this feature immediately since the bug is fixed. This is great news. I get to have my code deployed! Let's discover a few paths I went down to try to get my reverted changes back and issues that I can into.

For the sake of good story telling, let's assume a few things:

All of my work was squashed into a single commit.
I kept all of my work saved on a local and remote branch.
I did not run into any conflicts in this case since it was a new feature on a piece of the application that nobody else was working on.
Sometimes really dumb things happen in large teams when code is getting smushed together to be deployed.

Hey Dummy! Just Revert the Revert and You're Good!

At the very top of my list was just to revert the revert commit. Spoiler Alert! This did not work for me and was a crazy goose chase. Here's why.

The first step to this solution is finding the SHA for the revert commit. For some reason I could not find it in the Git log. It was simply in the comments for the tagged branch that was deployed. What I quickly ended up realizing is that the revert commit had been squashed into some other changes before the release, and that made for a sticky situation where I could not just "revert the revert that reverted my changes"

Hey Dummy! Just Rebase and You're Good!

git fetch
git rebase origin/develop

The second thing I tried to do was a simple rebase of my old feature on our develop branch, but that yielded nothing useful. If I rebased, the revert obviously removes my UI portion of the feature and we still have a problem.

Hey Dummy! Just Change the Commit SHA so the Revert Can't Revert Your Changes!

After resetting my local branch to the remote branch so I could undo the rebase changes, I tried this.

git fetch
git commit --amend
// Write new commit message to change the SHA of my commit to trick the git revert into not reverting my changes

git rebase origin/develop

This ended with the same result. The revert is smart enough to know what I am doing and if I look at everything after I rebase, my changes are gone.

Solution #1: One File at a Time

We want my changes from my feature branch to be in develop right? So one approach is to check our develop make a new feature branch and bring things over one by one.

git checkout develop
git pull
git checkout -b (some_new_branch_name)
git checkout (branch_where feature is) -- src/.../...(path to file)

Doing this approach I will have to bring in every file one by one and hopefully not miss anything while bringing the stuff over. I was not a fan of this approach since my changes were in half a dozen to a dozen files, and I did not feel comfortable with this in case I missed one of the files. This would mean an incomplete, or even worse, broken feature being shipped to production.

I think what I ended up with was slightly more elegant and got everything in one shot.

In the end, we have a branch with some changes that we want in develop, and those changes are squashed into one commit as the Git lords intended. All I really want to do is save those changes and apply them to my develop branch.

This was my "so called" elegant solution:

git checkout sexy_feature
git checkout -b backup_of_my_sexy_feature_just_in_case
git reset HEAD~1 
// The above will unstage and uncommit everything in the last commit.
git add .
// We need to stage everything since I added completely new untracked files
git stash
// This will put all of the staged changes into one stash
git checkout develop
git pull
git checkout -b bringing_sexy_feature_back
git stash pop
// Adds the changes into your branch, but not staged.
git add .
git commit 
// and you know the rest of the story from here

From here the story is bland where I submitted a PR and went about my day after losing a bunch of time in the Git downward spiral. Hopefully this post helps out some people running into the same issue.

Consider How Your Coworkers Work

Jeff Pereira — Thu, 06 Jun 2019 20:10:50 +0000

In our current day and age we work with a variety of different people. Some of us work with an office full of engineers that are all extremely different. Some of us work remotely and connect with people across or even outside of our own country. At times engineers become too focused in on the small picture of what work they do and become less cognizant of who they are working with and the traits of those people.

Building and maintaining a strong engineering team relies on the trust and relationships that exist on the team. There are delicate tolerances to everything that need to be kept in a constant balance. Understanding and respecting the traits and differences between all of the members on the team is critical. Let's talk about some of the areas where engineers can sometimes differ greatly.

How Much Work

There are some people that are the early birds, and others that are the night owls. There are some that dedicate their life to the craft and spending 14 straight hours pounding a keyboard is just another day in the office for them. Others are the adventurers and they feel their outside life takes a higher precedence, and they are in for eight hours a day, no more no less. There is nothing wrong with which you choose to be, but as a team member one needs to be sympathetic to how other people on the team choose to be. It is when some people feel a sense of superiority over others because they feel that their amount of time spent supersedes another's and they are better because they spend more time behind a keyboard than someone else. Contributions to a team are not measured in time spent, but in overall value to that team. Time spent is not indicative as to what someone is worth to a team. As long as someone is providing a healthy amount of time and contribution to a team, what does it matter if they are doing the bare minimum in terms of time?

What We Know

There are talented individuals all over with varying degrees of experience and talents. While being a member of a team we should take the perspective that the members of the team are a trove of information collectively, and only collectively will the team succeed and advance. Members of the trove might have valuable knowledge in one area, while others have a complete lack of experience, and it should be on the burden of the team to make that person great in all areas. If you have a team made up of 4 individuals and 3 are proficient at let's say Docker, and 1 isn't, you have a weak link in the team that needs to be strengthened. Don't deprive that person of the projects and knowledge in that technology, help them understand what that tech is and what it means to the team, and now that member is more productive and a better/more valuable engineer because of the sharing of knowledge. One of the key things to remember is that we should never be upset with someone else on the team because of some type of knowledge that they lack, because inevitably, that person will need to share some of their knowledge with you. In the end it is all about sharing.

Brain Speed

Some people have the uncanny ability to understand something the first time they ever see it and retain it. Others have to go through a series of repetitious cycles in order to get something engrained into their mind. There are people that can teach themselves anything, while others might need to be handheld a few times to learn something. There is no right nor wrong or better or worse in this case. As a team, there should be a focus on wanting to share knowledge habits. If we all teach each other something it not only makes for a stronger team, but it also gives the individuals doing the handholding experience in mentoring and teaching, which can be a valuable quality when bringing new engineers to the team. Always remember that no matter how intelligent you or others are, we all have our own pace and different ways we learn things, and we have to respect and acknowledge that.

Where I Lie

How much I work I do varies quite a bit. Sometimes I give my 8 hours and I am off to my personal life, and sometimes I see the need for me to work 10 plus hours to finish something. The majority of the time I am a 15 pieces of flare, bare minimum kind of guy, mostly because I value my live and sanity.

I typically do not program outside of work because I have too many hobbies. I have enough hobbies that I could probably lose a few of them, but as it turns out, I am more addicted to old rusty cars and working on my house than clacking the keyboard in my free time.

What I know also varies. I do not consider myself a pro anywhere. I am a clear sufferer of Imposter Syndrome, and think that I live in mediocrity while programming. Sometimes I surprise people here and there, but I don't feel that I am better in any one place than another. I do however have the open personality that I love talking to others and sharing my knowledge and experience. I think that is one of the main traits lacking in engineering. If you can make someone else great with your experiences, not only is it rewarding, but you make the team and people that you work with better in the end.

My brain speed varies based on coffee level in my system, complexity of what I am looking at, and overall experience with what I am dealing with. Sometimes I get frustrated when I do not understand something and I give up entirely too quickly, and sometimes I understand something in a snap. On a team, I think that most people will not understand anything and everything that comes across their desk, but if they're on a team that values its members, there should always be someone there to guide them and lift their brain speed in that area.

In the end it's all about being corny and the "sharing is caring" mentality. Engineers sometimes need to be more focused on the positives about the career that they are in and how they get to work on interesting things with talented people rather than dwelling on the negative aspects of their coworker's traits. Let’s all strive to be the good samaritan on the side of the road rather than the person that is judgmental and brings out the insecurities in others.

Self Worth and Negotiating Pay

Jeff Pereira — Thu, 06 Jun 2019 20:07:36 +0000

Imposter syndrome and knowing my self worth in general is something that I seem to have always struggled with. Since my days as a young boy in grade school, I always had the feeling in the back of my head that I was never good enough. I constantly compared myself to others and felt like I was short of their charisma or skill or something else. Nothing I ever did made me feel any different. I still struggle with this on a daily basis, but after attending a recent conference, Rails Conf 2017, I decided I wanted to vocalize this struggle and relate it to a common issue in the development world.

Firstly, I am not an expert in Psychology, nor an expert person in negotiating pay. What I can tell you, is that I can provide insight into the personal experiences I have had as a software engineer and IT professional for the last 5 years of my life. Over the course of this time I have gotten into a position I love, for a company I love, with coworkers I love, and with a salary I love. With the techniques I am going to speak about, I have also been able to increase my pay by 400% since starting in IT 5 years ago. This is partly because I was getting crummy pay when I started, and partly because I did a good job changing companies and asking for more money when I needed to. What I am going to explain has worked for me, but will not necessarily be as effective for other individuals. With that said, the single piece of advice that helped with with my struggle for self worth was when a team lead/software architect once said to me bluntly, "Stop fucking comparing yourself to other people. You're all fucking different and there is nothing you can do about it." While completely blunt and maybe not so work appropriate, this made me think a whole lot. He was completely right, no matter what I was ever going to do in life, I was not going to be like anybody else. I was not necessarily going to be the most wealthy person I knew, the most handsome, the best at programming, or even the best employee. One thing was for sure though. I got hired at the company I was at, and I had been employed there for a decent amount of time, so there must have been something about me that someone found valuable.

As someone that has interviewed and hired candidates for software development and other general IT jobs, I can tell you that it is not just a skill that someone hires you for, it is a complete package. An employer will want someone who works well with others, someone that shows initiative and leadership, someone that asks questions when they get stuck in the weeds, and among other things, a person that people can talk to. In many cases an employer can give up some trait in favor for another, but in the end what they are looking for is a complete package. In my case, I strongly believe that there are many developers out there much stronger than I am, but I do bring something valuable to the team. I tend to be what I call the "extroverted developer". I am loud, and in your face, and never stop talking, but at the same time, I am able to get stuff done, and sometimes provide a different perspective on something that a normal introverted developer might not be able to give. I think this, plus my willingness to always listen to others and learn from them are some of the best traits that I possess, and those are the things I like to focus on when I think of my self worth. I implore everyone reading this post to go out and find your amazing traits and focus on them, so you too will know how great of a person, and employee you are. You should also continue to focus on your weaker points as an employee, as that can only improve how awesome of a person/employee you can be. If you need help finding these traits, the best assets you have are your friends, coworkers, and superiors at work.

How does this all relate to pay?

First things first, whether you are negotiating pay as a new hire or as an existing employee, if you go into the negotiations as an individual that is not confident in his/her skills and attributes, you are completely doomed. I suggest you find yourself before you go out seeking more pay, because you will only be hurting yourself if you do not go in feeling at least good about yourself.

The Ugly Facts about Salary Negotiations

There are several things to understand about negotiating pay. These are items that most people do not like, and they cause discomfort, but we must understand them.

The employer in the negotiations is always trying to hire the employee at the price most beneficial to the company.
The employee in the negotiations is always trying to get the most compensation for themselves.
A negotiation will have back and forth. That is part of the process.
Negotiating pay is never something that is fun or comfortable. Go in prepared for battle.
Entering into negotiations on pay has its potential risks. Do not attempt to enter into these negotiations unless you are okay putting everything on the line. Yes, this can mean your job is potentially at risk.

Negotiating Salary as a New Hire

You need to know your worth to the company and your personal tolerances for risk. What this means, is that you need to leverage several things, like your skillset, saturation of this position in the market, and how much this particular company really needs you. For example, if company A needs a Go developer and you find out in the interview process that they really like to have people in the office, and you are the only Go developer in a 200 mile radius, you have a whole lot of negotiating power. On the other hand, if the company really needs a C#/.NET developer and there are 1000 potential applicants in the area, your negotiating power goes down, because in that large pool of applicants, it is likely that there are candidates just as effective as yourself, and maybe willing to take less money. So make an assessment of what you bring to the table prior to even asking about pay negotiations.

In order to make your negotiations the most effective, you must be able to risk everything. While negotiating as a new hire, you run the potential risk of a potential new employer saying, "We're sorry, but we don't want you as a candidate anymore." On the same note, we know that a company is normally trying to hire you at the cheapest price that they can, so if there are note even willing to negotiate a little, is that really the kind of company that you want to be working at? If you can't risk it all, don't negotiate and simply don't make more money.

Now we finally enter into the negotiations. Live and die by these quick tips. I included die, because remember that at this point, you are risking not getting this job.

Treat benefits as money. If they are going to pay 100% of your health insurance, think of how much money that saves you. If they offer a 401k, think of what kind of retirement that brings to the table for you.
Signing bonuses are stupid. Use them as a last resort and focus on negotiating your pay rather than a small amount of money. Would you rather have $1,000 now or make $700 more a year which leads to $2,800 over your next 4 years of employment.
Never be the first one to give a number. While the employer may try and trick you and ask you how much you want, hold firm on not giving the number, and simply say, "With respect, I would much prefer for you to give me the first offer to see what ballpark you are in." If you are someone that was really looking to make $80,000 per year, and the company was willing to pay up to $100,000 per year, and you decided to give out the first number, you just lost $20,000 that could have been in your pocket at the end of the year.
Always counter offer unless. Unless you are in that situation where you were looking for an amount of money and an employer offered you way more money that what you were looking for, make a counter offer.
Research research research. Be realistic about what you want in the realm of compensation and benefits. For example, you are not going to get an executive car package for an entry level position.
Screw what everybody else is worth, you are what's important. I once had a manager tell me verbatim, "I have C developers here that will be making less than you, and they have been programming for 15 years. What makes you think you're entitled to that kind of pay?" What other people with other skills make has nothing to do with your market value. Search your position and your skill set in your area and surrounding areas to make an assessment on what fair market value for you as an employee is. Never let anybody tell you what you are worth. You can answer that for yourself.

With these simple tips, you should be able to negotiate with an employer and reach a price that is efficacious to both you and the employer. If they have problems with negotiating, remember to explain this to them. You respectfully understand that they are they to get you as cheap as possible for the company, and you are there to be as successful as you can be. If they still decline, go back to thinking about whether this is really the kind of place that you wanted to work at all along.

Negotiating Pay as a Current Employee

You need to consider all of the same things as a new hire with one very large additional fact. The largest raise you will ever get is normally by changing employers. This is something that you must consider if you are uncomfortable with pay where you are currently at. Given the example of a software engineer where pay can range from $45,000 per year to over $200,000 per year. If you were hired in as a junior software engineer, and you were making let's say $50,000 per year, and you get to the point where you are mid level and should be making $80,000 to $100,000 per year, it is going to be really hard for your superior to justify that kind of increase to a CFO etc. I am not saying that this kind of pay adjustment cannot happen, but I am saying it is wildly unlikely.

With all of that said, I wish you luck on the adventure of finding your self-worth and future pay negotiations. If you are a Ruby on Rails developer or any other developer, and looking for some additional advice on negotiating pay, check out the Ruby Rogues podcast. They have some good episodes on this subject.

Ruby Rogues Podcast: https://devchat.tv/ruby-rogues

Good Sources for market on salaries:

Why Everyone Should Learn to Program

Jeff Pereira — Thu, 06 Jun 2019 19:53:37 +0000

Regardless of what field you are in, or what you do for a living, one should always draw in knowledge from other disciplines and make a fair attempt to relate its practices to what you are doing. Studying mathematics, science, and english has helped me greatly in my programming career. It is not always computers, processes, threads, and programming language syntax all day. I make my fair attempts to learn about new and useful subject every single day. I feel that having a broad range of knowledge can only help you become a smarter and more professional individual.

When I say that I love to learn about new subject, I am not suggesting that I nor anybody else just read an article and assume that it is sufficient and that they have become a de facto master on said subject. I recommend tapping into your own bit of insanity and OCD and becoming temporarily obsessed with a subject. Learn the who, what, how, and why around whatever it is that you are researching with particular emphasis on the how and why. With all of that said, here is where I will state my case of why I believe that everyone should learn to program.

Not everyone in this world will become a great athlete, a doctor, a great chef, or a great programmer. This does not however mean that we should not play sports, learn about medicine, learn to have some skills in the kitchen, or make an attempt to program even at a low level. Software is something that surrounds us everywhere. It is all around your house, your car, and for the majority of us, our careers. At some point every single day a majority of our population uses some kind of software to make some task more automated or efficient. I think too many people in this world take that for granted and never make attempts to understand how or why software works.

Learning to program is not something simple, and it will cause frequent fits of rage, and shaking of fists at a computer monitor, but it is all worth it. Even if you do not plan on becoming a full time software engineer, it can teach you a lot about logic, and problem solving. Additionally, I believe that people that program are many times more self sufficient and able to research at a higher level than people that have never tried it. Learning to program forces you to move into the unknown and teach yourself a lot. There are a lot of resources out there that can help you solve your problem, but it is ultimately up to you to start. If you have children, having them learn to program is a great way to open their minds to concepts that will not only make them smarter, but give them capabilities to teach themselves things which is an invaluable attribute the younger someone is.

If you feel that it is the time to unlock your potential by making the leap into educating yourself about learning to program, I suggest that you do not hesitate on taking action on that idea. As a Ruby on Rails developer, I lean in the direction of learning Ruby, but learning any programming language is great. Below are some great resources to set you on the path to learning to code. If you decide to go on this journey, I urge you to take a stand a spread the word. A world with smarter people is a better world.

NOTE: In this particular case, given that the target audience may not know how to program in any sense, I recommend Ruby since it is very easy to read and allows for the user to get to a success path a little more quickly. While on this journey should you have questions or need help, I extend my personal assistance to you. Feel free to message me. No guarantees on how fast my replies are, but I will help my followers as time allows.

Beginner:

Learn to Program
Online course by One Month

Intermediate:

Agile Web Development with Rails 4 (Shopping Cart Book)

Advanced:

The Rails 4 Way The Well-Grounded Rubyist

How a Friend and Engineer Changed My Life

Jeff Pereira — Thu, 06 Jun 2019 19:50:58 +0000

As this being the first post of many to my writing about life as an engineer, I will preface this with a little bit about what my write-ups will be about. I will be writing about the technical and non-technical aspects of my software engineering career. Even if you are not a technical person, I hope that some of my writings will inspire you. Whether you go out into the world and become an aspiring software engineer, or it just makes you feel good for a minute, I am looking to connect to someone with my thoughts and experiences from my profession.

As an attempt to introduce myself, I am Jeffrey Pereira. I am a 29 year old software engineer for a small security startup called Malwarebytes. I have been writing Ruby on Rails applications full-time for the last two years. I am neither a junior level engineer nor am I a senior level engineer, I am just a regular guy that tries to bust his ass and write the best code that I can. At a recent trip to Rails Conf, I was inspired to begin writing about my experiences as a developer, so here is my feeble attempt to amuse. Apart from my introduction, this first post will serve as the story of how I got into software engineering. It begins with the story of my best friend.

Throughout your life there are people that you will end up meeting that will literally change your life for the better. Keep those people as close to you as you possibly can, because if they can do it once, the likelihood is that they are going to do it again and again. In my case, this story starts in my junior year of high school where I met, John, the guy that would end up being my best friend. Our friendship did not turn into much right away, but one day he overheard that I was looking for a job, and told me that McDonald’s was hiring, and that he worked there. Over months that I ended up working with John, we became better friends. At this point, little did I know that this would be the one friend I had that would push me into making the choices that would go on to change my life forever.

Fast forwarding to my early twenties, I was a part time college student taking two classes a semester, working at a Best Buy store getting paid peanuts to walk into a job that I hated. All this time, John had gotten into an IT support role, and was way more put together than me. This started to push me into the mindset where I knew I was doing something wrong with my life, and I was looking at John no longer as a friend, but someone I wanted to aspire to be. Eventually John ended up scoring a job as an Integration Engineer for a small credit bureau, and after about a year went by, he gave me the tap on my shoulder and said it was time. He got my foot in the door to what would be my first job ever in IT. Not only did he get my foot in the door, everything I learned in that position was due to John being my mentor and trainer there. Working there was a whole new experience that I loved, and I knew at that point that working somewhere in IT was definitely for me. Eventually John went on to become a Rails developer at this company, and I stayed as an integration engineer. Several people came through my department and went on to become a developer, and I stayed there in the bowels of IT.

While John was quickly becoming not just a good, but a great developer, I was struggling to put together the pieces yet again. I did not understand why he could go on to become this great Rails developer, and I was stuck in the integration department. Again, I looked to John for advice, and this time he had a lot less to say to me, and it was a bit of tough love. He basically told me that development needed to be something that I wanted, and I needed to try and figure it out myself. This statement pissed me off quite frankly. Why couldn’t John just teach me what he knew? Why couldn’t John just get my foot in the door with development like my entry level job in IT? Well after thinking all of these selfish thoughts, I realized what it all meant. Teaching yourself how to become a programmer is about dedication, inspiration, and suffering. John went through this right of passage, and and because of his trials and tribulation, he went on to become something great. This is not something where you can have your hand held, you must go through it on your own. This is the point where I decided to man up, buy some books, take some online classes, and start building my own application. My original application that I built, is still on Github (https://github.com/jeffpereira/pinteresting), and it sucks. It is ugly, and buggy, and most of the code in there is super basic and terrible even. Many people ask my why don’t I work on it, and why don’t I take it down so people do not see it, and just tell them that it is there to remind me of where I came from.

Fast forward a few more years, and John is now a team lead for an engineering group at a startup that looks to be on the brink of becoming something huge, and I have scored my dream job at Malwarebytes where the atmosphere is great, and I am surrounded by people that motivate me and help me become a better developer every day.

At this point you may ask yourself, this is a charming story, but why is it important? To this I say that we should all try to be someone else’s John. We should all try to inspire someone to be better, or to work harder. There is always someone out there that needs to be pushed into a direction where they can become a better person, and with more Johns in this world, we as a people will only become better. I still talk to John every day, and he still serves as a source of both inspiration, and what I aspire to be, and I still have that project to show me how far I have come.