Query Optimization Developer in Cambridge, MA, United States

Running this group project was my largest accomplishment so far. I managed a team of 3 (myself included) developers to design and create a planning and budgeting tool for our clients.

Project Roles
· Project Manager
· Database Developer
· Report Developer Number 2
· Web Developer Number 3

We had one main web developer whose job was to combine all of our work and integrate it into our already existing tools. The other developer was about 80/20 report developer and web developer.

The project took us about three months to complete from inception through planning, development, QA, and release.

Our end-user base team consisted of about 40 users from data tracking and the report consumption.

What I learned from this project was:
· Requirements gathering and weekly client-update meetings are important.
· Clients tend to change requirements as you go, especially if beforehand they didn't know exactly what they wanted.
· Test-driven development is an important skill.
· Make the project scalable, because sooner or later, you will need to add in something new.

I managed and developed on a team project building a ticket-tracking tool for internal requests including projects, ad hoc database queries, bug fixes, and other uses of time.

There was a total of three developers. We discussed having a better way to track our work, and we started storing the numbers in a preliminary database. From that, the web developer would build the tool to fit into our existing internal C#/.NET web application. I wrote the initial SQL scripts for the team to play around with and worked with our manager on finding what he needed to report on. A third developer and I also worked on developing the SSRS reports

I assigned out tasks for each of us to work on, with time-frames and gave them to the qualified team members. We reported biweekly for progress updates and brainstorming sessions. In the end, the tool was used every day to track our work and projects. Our manager also used it for future project planning, and C-level reporting on a monthly basis.

What I learned from this project was:
· Every developer has their own way to track their work.
· Biweekly stand-ups are not enough, daily is probably better.
· Give the work to the people best suited to the task.

Contracted for 3.5 months to work alongside a major company rebranding and website rebuild.

My role was to work with the data scientists and analysts on presenting the data in a Kimball star schema (with fact and dimension modeling) in the new data mart. We used PostgreSQL and a tool called Data Virtuality to have real-time looks into our Google Analytics and live databases.

After creating the new data mart, I then trained users on how to use it and helped analysts in building reports in Looker, a BI tool.

Took a deep dive into the client's Looker and BigQuery data to analyze spend and usage. Analyzed best practices and consulted with users on maintenance and continuing cost reduction.

I helped cut costs by over $150,000 in queries alone and directed them on how to keep their costs down. Also provided best practices documentation, and directed on training going forward.

Things I learned from this project:
· Looker Admin explorers are quite robust.
· I learned how to utilize BigQuery.
· If the only access to the database you have is through a reporting tool (such as Tableau, MS Report Builder, Looker) you can get to what you need—only if it's available—with a lot of round-about solutions. Having access to the database itself is a much better use of the consultant's time.

I rebuilt the database and ETL process from a Python and MySQL database into an SSIS and MS SQL database. The original application had over 450 tables including unnecessary staging tables.

By the time I had completed incorporating it into the MS SQL data mart (removed data redundancy as well) and completed recreating the ETL (of the ~20 data sources, only about 5 were unique), I reduced the tables to about 80 including views and trigger-populated activity history tables, and reduced the run-time from almost 10 hours for 50 million rows to just under 3 hours.