DEV Community

Cover image for The beginning of my professional journey as a dev
David Pereira
David Pereira

Posted on

The beginning of my professional journey as a dev

Hello, my name is David and I'm from Portugal. I'm officially a pokemon trainer that seeks to be the very best, like no one ever was 😁. No, but jokes aside, two months ago I became officially a software developer, leaving the exciting college environment because I'll actually work on a project for a company, with real clients.

Since this is my first post on DEV, I'd like to share some of the experiences I've had and a bit about my last semester studying Software Engineering.

My final year project

On my final year project, I wanted to go over the top and apply all I had learned on my Concurrent Programming, Security and other classes. I planned on learning Docker since I heard so much about how it helps to deliver software. My team and I (a team of 3) were very ambitious on features too, at least at the start. I researched a lot about agile software development and other stuff like CI/CD (Continuous Integration and Continuous Delivery or Deployment). I watched some videos from mpj, who is the guy behind a very awesome YouTube channel called FunFunFunction, about using CircleCI. My goal was to have at least some tests running, and making sure the project builds on a machine that isn't my own. Maybe saying to your teachers "But it works on my machine, do you want to see it?" works, but in the "real world", it's not really feasible... most times. I suspect that you get away (sometimes) as a student with this behavior, because teachers don't really expect, or don't enforce this to be a practice. But bear in mind this is just my opinion, given what my experience at college was.

Building software for a company

But now that I'm working on a project where the scope is way bigger than any school assignment. Applying some ideas of agile software development simply makes sense. Having a board on GitHub with tickets planned for a sprint, where the tickets are labeled with their estimated size so that we can decide better which one to do next, is truly helpful. Adding other labels to distinguish if it's a feature or a development improvement (maybe some refactor), helps to prioritize our work.

Pull requests aren't something that I use, just for the sake of using them anymore. I used to do them at some of my school projects (definitely more this last semester), but merely to integrate the changes of the different team members. And a lot of times there were such massive PR's that not even praying to god saved us from merge conflicts 😫. But now at work, I realize that this is a great place for a code review or if the team follows some branching model, for example. A reviewer can be assigned to the PR and then leave comments as he sees the code, and request changes. You can also setup your CI environment to have these so-called "checks", that are rules that your PR needs to pass. For example, you can have security checks to assert that you don't have any dependency that has high vulnerabilities. I believe there are other rules like "at least one reviewer needs to approve this PR" or "You can not merge the PR until all checks pass because the branch is protected". Suffice to say that there is a world of stuff that I can still learn about 😁.

Learning from Senior Devs

I think it's awesome to work with senior developers because you learn a lot from them. For example, part of the code that I wanted to write in React hooks was to solve this problem. With the help of one of my colleagues, we wrote our hook for this, so that it could be used in any component:

export function useEffectWithCancelToken(fnFetchData) {
  const fetch = useCallback(fnFetchData, [])
  useEffect(() => {
    let cancelToken = { isCanceled: false }

    fetch(cancelToken)

    return function cleanup() {
      cancelToken.isCanceled = true
    }
  }, [fetch])
}
Enter fullscreen mode Exit fullscreen mode

I think being confronted with challenges of all sorts, and being side by side with a senior dev, helped me learn how they think and go about a problem. Not to mention the exposure of knowledge and past stories they have to offer. So far I learned a lot more about CSS/Sass, responsive design, structuring a project and environments (e.g. production and staging).

Being faced with challenges

To be truthful, most days are filled with development challenges, and I run into lots of problems (mostly CSS related... what can I say, front end is not easy 😅), errors and some tough decisions. There was one problem that I was stuck on for 3 days. This felt like an obstacle that I couldn't even figure out a workaround, and there were many times when I thought I had figured out the problem, but in reality, I was way off.

If you are feeling demotivated or you don't feel like you're being productive at work or even school. That you spend the whole day debugging, console logging, watching errors happen left and right. Just try to hold on to something that doesn't let you quit. Because I'm telling you right now, the feeling you get once you solve the problem, it's totally worth it. You'll be ecstatic, you'll want to scream "HECKKKKKK YEAHHHH", you'll have a smile on your face that won't disappear for a while... at least that's what happens to me and what goes through my mind in those situations 😄.

Anyway, before I explain the problem, imagine this piece of code:

// imports...
export function Wizard ({ children }) {
  const [activeStepIdx, setActiveStep] = useState(0)

  return (
     <div className="wizard">
       <div className="wizard-content">
         <Step />
       </div>
     </div>
  )

  function Step () {
    const activeStep = children[activeStepIdx]
    return <div className="step">{activeStep}</div>
  }
}
Enter fullscreen mode Exit fullscreen mode

Now lets say the component that uses the Wizard is like this:

// imports...

export function CoolForm() {
  const [email, setEmail] = useState("");

  return (
    <Wizard>
      <Form initValue={email} onChange={setEmail} />
    </Wizard>
  );
}

function Form({ initValue, onChange }) {
  const [email, setEmail] = useState(initValue);

  return (
    <form>
      <Input
        name="email"
        type="email"
        value={email}
        onChange={e => {
          const { value } = e.target;
          setEmail(value);
          onChange(value);
        }}
      />
    </form>
  );
}
Enter fullscreen mode Exit fullscreen mode

The issue here is that the input on the form loses focus when you type anything, which means you have to click on it again to type something again. This happens because when we set state on the change event of the input, React re-renders the Wizard and the Step component as well. But why does the Step component gets unmounted? That was precisely one of the questions I had, and it took me a while to see the real problem. I found this post that helped me.

The solution is to move the Step component outside of the Wizard, because if it's being defined inside it. Every time the Wizard re-renders, a new function will be created for the Step component. Initially, it was being defined inside the Wizard, simply to have access to some variables (through a closure) defined on the Wizard. Of course, the complete implementation has more variables that I wanted to capture than the snippet above.

Here are the links for the problem and the solution on CodeSandbox.

About TODOs in code

As a junior dev, I find myself having to ask a lot of questions, but most are about decisions that I prefer to be done with the team. This leads to a lot of TODO comments 😅, so a cool practice that we started using to be able to filter the TODOs by a person was adding the name of the team member that wrote the TODO. Maybe in a bigger team or company, it would be better to use the Github username, since you might not know how to contact that person just by its name. Here is an example of the format I use for TODOs and the extension for VS Code that I use:

// TODO: (David) Refactor usages of "export default" to variables or functions
Enter fullscreen mode Exit fullscreen mode

Conclusion

On a final note, there is nothing better than coming home from a full day of work and just play some games and chill. It's the best! Especially on Friday.

I hope you enjoyed reading. In the future, I'd like to post more about some of my work, specifically my final year project since there is a section about building applications that follow the REST constraint called Hypermedia as the engine of application state (HATEOAS). But also just stuff I learn (like the amazing flexbox in CSS that I'm loving to use right now) and thoughts I have (I tend to think a lot 😅). In doing so I hope to document my journey, the good bits and the bad too, and perhaps even help someone in the community.

Top comments (2)

Collapse
 
songomen profile image
SongoMen

Hey, good job! I am jealous you have people to work with. I hope that in the future I will find someone that loves coding like me and would like to work together.😀

Collapse
 
bolt04 profile image
David Pereira

Hi, thanks 😄. I'm sure you will, just keep working and learning 👍