DEV Community: Camilla Santiago

How to make code reviews developer-conflict free?

Camilla Santiago — Thu, 30 Jan 2020 00:48:26 +0000

Code reviews seem to be a blocker on our team ever since. It is big, it takes time and it slows our delivery. Personally, I am having difficulty giving feedbacks and comments. I am torn on enforcing code standards and suggesting practices, and reducing frustrations for the developer. We are , most of the time, fast-paced so the developer usually have another task to work on. I feel like I am being the blocker by giving too many feedbacks when the developer should have moved on to another task.

How do you do it with your team? Quality of the code or quality of the human code? Where is the balance?

Why you should join a hackathon at least once

Camilla Santiago — Mon, 25 Feb 2019 01:30:03 +0000

The two-week hackathon I joined just ended. Here are the things I learned and why I would be more than happy be on another.

You get to expand your toolset

Your hackathon entry maybe totally out of the box of what you usually do. You get to decide what tools, libraries, and languages to use! It's a chance to learn new stuff. Experiment. Discover. Put your ideas to the test. Do the things you always wonder about. Then after, you can confidently put these new tools on your belt bag.

You get to socialize with other devs (even if you don't want to but will be thankful in the end)

Hackathons let people group themselves. If you want to work with your friends on other teams/companies or you're interested on other team's idea, asked to join or was invited but is too good to decline or got no other teams to take you in. No matter what situation you're in the point is you get to work with people. You get to brainstorm, develop, cram and celebrate together. I think on its own is already a win. In the end, you get to expand your contact list with new tech people. Maybe even win some new friends.

Conclusion

Joining a hackathon will get you to learn and have fun! Try joining one (or more) and you might be surprised at the results.

Why Git Alias

Camilla Santiago — Thu, 02 Aug 2018 05:08:58 +0000

I've been using git aliases for a while now. People have seen me using them, asked me, I explained, encouraged them to use it too and failed. Why?

Perhaps my convincing powers is not that effective so I will try to appeal one more time.

Git Alias

Git aliases are shorthand for git commands. Just add it to your ~/.gitconfig.

[alias]
    st = status
    ch = checkout
    chb = checkout -b

Now, instead of typing checkout -b, you can just type chb.

git checkout -b bug12345
git chb bug12345

Cool, right? So, what else?

Why Git Alias?

It's cool!

Yes, I've said it again. But isn't it just cool, really? Being able to accomplish multiple commands in one go. While others execute git commands one by one, you take a shortcut and use aliases. Doing something out of the traditional. Gotta admit, it feels badass to use git aliases at times (especially when pair programming)

It saves time

I don't think I need to emphasize this more. You can stage, commit then push your changes in few clicks. Which will save you more or less 10 seconds, considering you commit roughly 10x a day, can save you at least 2 minutes a day. Which you can use to fix your coffee, go to comfort room, update your code reviewer or just stretch and have a quick nap.

My git aliases

Here are some aliases that I frequently use. All, I share here.

[alias]
    #current branch
        me = !git rev-parse --abbrev-ref HEAD
    #publish
        up = !git push origin -u $(git me)
    #unpublish
        down = !git push origin --delete $(git me)
    #stage all then commit with message
        acm = !git add . && echo 'Staged all changes, if any.' && git commit -m $message

I recently discovered the fixup git alias here. It lets you amend your staged changes to a specific commit.

fixup = "!f() { TARGET=$(git rev-parse "$1"); git commit --fixup=$TARGET ${@:2} && EDITOR=true git rebase -i --autostash --autosquash $TARGET^; }; f"

To use, just provide a few SHA-1 hash of the commit you want to amend to.

git fixup d670460b

Then voila! Your recent staged changes should be fixed up to that commit.

There are lots of possibilities you can do with aliases. For one, when resolving rebase conflicts, I also use git alias to open TortoiseGit and execute diff on my source files. It's up to us to discover these possibilities.

Why Not Git Alias

X: So what's the git command for publishing branch again?
Me: git up
X: not a git command
Me: (Remembers it's an alias) Oh, wait. Let me check.

Okay, because you use aliases it's normal to forget the original commands. There's no escaping that. But don't worry I got your back. There's also a git alias for that.

# list aliases
    la = !git config -l | grep alias

Use git la to list all your aliases and the corresponding commands. Great way to hack around using git aliases.

Conclusion

I hope I introduced Git Alias enough to make you try it. Just want to share the bliss of using it. Hope you also find it useful in your daily programming experience.

For others using it too, care too share your favorite aliases? What do you like the most about it?

For others who don't, why not?

How does your development process look like?

Camilla Santiago — Wed, 06 Jun 2018 02:23:43 +0000

I'm part of a small team and we're trying to redefine our development process to be more effective and intact. I want to have insight on how other teams, big and small, does it. Can you share a walk-through of your development process, from ticket to release, or alike. :)

Explain reference and value types like I'm five

Camilla Santiago — Wed, 30 May 2018 23:22:45 +0000

How to involve internal QA team in Software Development Process without disrupting the Dev team process?

Camilla Santiago — Sat, 03 Feb 2018 07:37:57 +0000

Situation: So, we are now doing daily stand ups and did the first retrospecive after a long time. Each team member was asked to put out their Sads ☹️ and Glads 😊 for the past sprint. But because it was the first time in a long time, we came up with a really long list from since the beginning. But the most Sad that I think needs to be addressed first was:

The QA team feels their role is neglected

Currently, we have three teams, i.e. devs, qa, implementors. QA team is supposed to be the bridge for the devs and implementors. QA files the feature requests and bugs found by them and implemetors. Devs deliver the updated version then QA performs tests and, if pass, releases to the implementors. What currently happens is that because of strict deadline, implementors are forced to use untested versions. I know. I know, sorry. But also, when the user discovers a bug, which is expected, the QA team takes the blame from the Project Manager. 🤢

What's the solution?

It's obvious that our process flow needs to be reconstructed. So I'm thinking of taking the QA team as the internal QA with the devs which will comprise the whole R&D team. Devs and QA are to work closely together to deliver the software. QA are to perform integration and funtional testing before devs can merge their changes to master repository (we are using git, btw). But. But. But I am thinking, as a dev, what a setback! Now, I need code review and QA approval to complete my pull request. I know I said 'work closely together', but still. Maintaining a develop branch also looks like an option. But I think that's just putting the load somewhere else on someone else. I know there should be something we can do about this. Maybe a new process flow? Maybe just restricting the implementors to access the builds? Help. 🙏

Tips on improving teamwork

Camilla Santiago — Sun, 21 Jan 2018 04:05:59 +0000

Situation: Team lead graduated from the company and previous team practices, i.e. scrum and retrospectives, are also discontinued since no one stood up to the position. Now, team is less enthusiastic and juniors feel helpless at work. I figure this is the time to act but is clueless on what or how to.

What practices can you advice to improve team work?

Revamp scrum and retrospectives? Truth is, I am not a fan of scrums since I am not good at interruptions. Gotta confess that one day, I proclaimed, "Let's not have scrum today" and so it was set on stone. I am thinking that maybe we are losing the true essence of these practices. Its not just a group of devs waiting in turn to say their tasks for the day, isn't it? Please enlighten us on these.

I'm also thinking of mentoring sessions, though I suck at that, but I strongly think it will help the team. Its a hurdle. So please can you also advice on mentoring, pair programming and such.

Leadership sure is hard.

Thanks in advance!