Hello from Dylan and Brett at Tilde again, posting one last time. We're finishing up our internship at Tilde and moving out into the great big world of software development long-term employment. But before we do that, we wanted to share a bit about our experience.

The project

In our previous post we talked about our main internship project and some of the early challenges we ran into. Tilde needed a new admin panel that could improve the user experience and build on existing functionality, and the designs were ready: just needed to be built. The admin panel was set to be a greenfield app using a new Rails API and Ember.js on the front end, incorporating third party APIs, data-visualization, and critical tools for the team: cool!

The process

The designer provided a Sketch document with mockups and some technical requirements—like that front-end needed to use Ember.js :)—but apart from that it was largely up to us to decide what features to build when, and how. Our methods and communication with the team changed over time as we became more familiar with development out in the wild and "the Tilde way."

Early on, we met daily with a dedicated mentor to ask questions ranging from the best way to approach a feature to how to improve code we'd written earlier in the day. We thought this was an excellent way to emphasize that in an internship, asking questions is ok and expected. It wasn't all fluff and hand-holding though; during the first week we needed to demo new work daily. Presenting to senior engineers was intimidating, but also highly motivating!

As time went on, we presented to the whole team and met with our mentor(s) less and less. This wasn't because we were any less busy or didn't have any questions though. It was a function of learning to solve many of our problems by getting help in more low touch ways, like through Github PR reviews and Slack. In our opinion, learning how to effectively collaborate with a team of engineers was perhaps one of the most important skills we learned as interns.

Rookie mistakes

We worked on a challenging project and were certainly not micromanaged, so this gave us room to make plenty of mistakes! As Coolio might say, we were living in a learner's paradise. Here are a couple of the learning experiences that really stood out to us:

1) Avoiding rabbit holes

In the beginning, let's face it; we probably relied too heavily on the developers around us. There was always someone around to answer questions, amazing!

As we became more confident though, sometimes we'd go off on our own for long periods of time. We probably thought we should give our teammates a bit of a break.

That said, "going off into the woods" wasn't always the best way to approach a problem, because sometimes we'd approach a task the wrong way and get pretty stuck. The challenge for us was learning how to strike a balance between complete independence and over-dependence.

One of the ways we began to use developers around us as a resource instead of a crutch was to say something like "Hey, we're going to do this. Let us know if that sounds like a terrible idea," and then go off and work on the feature. That way we were able exercise our problem solving skills without getting lost down a rabbit hole, but there was at least some opportunity for any major mistakes to be noticed by the team right away.

2) Respect the docs

The Tilde team really emphasizes the importance of thorough inline documentation, something that was almost entirely new to us. Whenever one of our pull requests was lacking documentation, we were gently reminded by our mentor to document everything.

Although writing documentation is a great way to review and better understand code that you've written, we didn't always keep on top of it. Eventually, we'd remember to write documentation, but would procrastinate until it was time to open the PR, which would also sometimes lead to sloppy mistakes. The lesson learned? Document everything, document well, and document often.

3) PR size matters

A final takeaway was the importance of managing pull request sizes. We went the first two weeks of our internship without opening one, so when we finally did, it was a nightmare to review. No one wanted to touch such a huge PR; it would take hours to review, so who could blame them?

We quickly learned to make more smaller PRs. In addition, no one wants to review a PR if they don't know what is happening in it, or how to get the code working. Putting plenty of detailed description of your expectations for the code, as well as instructions on how to get it running in development, was a great way to ensure that the team would look at and approve it more quickly, allowing us to keep working.

The result

While we didn't completely finish the app, we did make a lot of progress and we're all quite proud of our results.

One great thing about working at a real company is that you get support from designers. Having high fidelity mockups as a reference point made us feel great about the front end development work we were able to turn out.

As an added benefit, there was no doubt about what work was expected from us. It was strangely liberating and motivating to be able to visualize what we wanted to accomplish, and having that be our goal. Below is an example of one of these comps; it was extremely satisfying to be able to mimic it completely and bring the designer’s vision to life.

Here's a gif we made a couple months ago showing the sleek layouts we were able to churn out.

During our internship we were able to work on well designed UIs, dive deep into numerous third party libraries, detangle legacy APIs, and design new ones. The most valuable experience though, was working with the great people at Tilde. If you have the chance you should too! I hear they have a job description out for senior developer position :D

If you have any questions or comments about our time at Tilde, feel free contact Dylan or Brett.

Want to appear on our admin page? Sign up for your 30-day Skylight free trial! Or refer a friend and you both get $50 in credit.