Checkout Bunch in New York City and San Francisco!
‘Raduation Day. I am so happy with our team’s final project. We spent most of today perfecting and rehearsing out presentation. Our app totally works live on Heroku after only 2 weeks’ work. I am happier today than my college graduation!
Here’s a full video demo of how Bunch works:
It works and everything on Heroku: bunch-us.herokuapp.com Check it out!
We partied ’til late like we Makers do.
I’m now a Junior Ruby/RoR Developer seeking employment!
Thanks. In the meantime, I’ll be
During lunch the day before our graduation, Ali gave us an awesome on How to Kill It After Makers.
He says that the wildly successful people he’s encountered in circumstances similar to ours shared these traits. He broke this traits and tips into two parts: before & during Makers Academy, and post-Makers Academy.
Before & During Makers Academy:
1. WORK ON SMALL, FINISH-ABLE PROJECTS.
Keep the habit of shipping software regularly on GitHub. This can also serve as a constant way of applying newly acquired knowledge. But be sure not to be overly ambitious and let that stop you from shipping. Go from something simple like printing ‘Hello Word’ to making your program do more sophisticated things. Check out Jennifer Dewalt’s 180 websites in 180 days for some inspiration!
2. WRITE REGULARLY AND PUBLISH.
This should be work related and technical. Julia Evans writes 200-300 words a day for her blog: https://jvns.ca/ I guess I’m semi-on-top of this since I’ve been running this blog. I need to try to get more technical though.
3. HAVE VALUABLE IDEAS TO SPEAK ABOUT AT EVENTS AND MEETUPS
Speaking at meetups is a great way to build credibility and <secret tip> the bar for speaking at local meetups usually isn’t that high, but you look like a total expert regardless </secret tip>. It doesn’t need to be something you know extensively about, but anything you can talk about for about 30 minutes would be sufficient.
4. MEET PEOPLE AND CREATE A NETWORK OF PEOPLE WHO HAVE YOUR BACK.
Do this by attending meetups and keeping in touch with people you’ve worked with and staying in the pulse of things so that you don’t miss out on unpublished opportunities.
Getting a Job
1. COLLECT A HUGE LIST OF LEADS.
Just anything under the sun that you would be remotely interested in. Bookmark them and have a huge list. Not many companies advertise junior roles, so just mention it when you are networking to collect leads. Inbound leads and leads through your network are the best.
DO NOT USE RECRUITERS.
I asked Ali about in-house recruiters and they seem to be okay, but having a recruiter or recruitment agency as your main source of leads is like slowly sitting on a very long, thin pole. They are incentivized against your interests and would probably hurt more than help you AND the company you’d like to work for.
2. DECIDE WHAT’S IMPORTANT TO YOU, REALISTICALLY.
Big company vs small company? Big vs small tech team? Go somewhere where there are dev slightly better than you. Think about your learning goals and skills development. As junior-juniors, it’s quite important not to develop nasty habits at companies that don’t know what to do with a junior. But money might be an important factor for some people while other care most about location.
3. SEND OUT CV AND COVER LETTERS.
Be sure to have JUNIOR DEVELOPER SEEKING EMPLOYMENT highly visible on your CV. Show shipped software on GitHub, then education, then maybe nice things other people have said about you if you have two pages. For an American CV, there’s probably only room for the first two things on one page. Cover letters should cover big topics and questions such as how you might add value as a junior or some sort of critical understanding of the company you’re applying for.
4. GET INTERVIEWED.
First there’s fluff, and people are just trying to see if they like you. Then there’s the technical challenge which is usually the majority of what dev interviews are made of. A good way to start is usually to repeat their question back to make sure you understand what it is being asked of you. Ask to clarify assumptions and ideas rather than starting to type code immediately. This behavior is a major red flag. Don’t be afraid to say “I don’t know… but maybe I would look into this/that” or “I don’t know, but could you tell me about it?” If they refuse to tell you about something you don’t know, it’s probably not a stellar company for a junior dev. How can you be expected to know everything after 3 months?
Be prepared to ask them some questions. Some generic starters: What are you working on? What’s the best/worst thing you find about working here? Who do you report to? What’s the culture like?
5. NEGOTIATE SALARY.
Have 3 offers. Ask for £36k. Ask companies to wait a little bit longer for other offers to come in so you can choose the offer you want and 3 is a good number for you to be happy with the choice you made. If you don’t have 3 offers on the table or can’t afford to wait, ask for £36k. This number is for London. But the point here is that companies hiring a junior dev can definitely afford to pay £36k and you need to ask for that number if they don’t offer this to you. Just email them and say you need £36k and don’t make a move (i.e. cave) until they get back to you. It also doesn’t hurt to negotiate because the worst they can say is ‘no’ and you are back to where you started. It’s not like your offer goes away because you asked for more money. And if they say yes to £36k when they initially offered £33k, then a single email made you £3k.
If you find Ali’s advice here as helpful and enlightening as I did, then check out his free e-book that you can download at Happy Bear Software: https://happybearsoftware.com/kickstart-your-developer-career.html
Last day before graduation! Look at our Trello board with everything done!
I’m spending today getting the tests that my automatically appearing input boxes are breaking.
Implementing the functionality wasn’t all too difficult, though I still had some help from Alex, because things never work the way I think they would or should. The functionality was there by the time I left Makers yesterday evening. I first had the new automatically-generated input boxes show up in 100% opacity because I had broken about 6 tests. Not too bad. I just went in and fixed the cucumber tests one by one and it was basically taking out the step that involves clicking a “+” button and going ahead to the “fill in next address” steps.
Then, when I wanted to make new input boxes semi-transparent until they were focused on (to be typed into) before having 100% opacity. I did this by making a ‘waiting’ class for the input box that is ‘waiting’ to be used. The waiting box will have semi-transparency until it is focused on and .removeClass() is used to make it just a regular input box, giving the next automatically-appearing input box the ‘waiting’ class.
Look at how sexy this is! (Address 3 is where the input cursor is currently.) Give it a go at http://bunch-us.herokuapp.com/!
During lunch, we had an amazing talk from Ali on How to Kill It After Makers. It seems he has given this talk to Makers a couple of times and always received great feedback.
Then all the groups had a dress rehearsal of their presentations in front of the junior cohort and other teams. I was pretty happy with our team’s dress rehearsal presentation and I think it can be quite polished by graduation.
Pivotal Labs hosts a series of fantastic tech talks every Wednesday, and I attended one given by Margaret Pagel, Vice President of Sales Marketing at 8th Light, on Improving Communication. Margaret shares with us her advice on being a good communicator from her careers in sales for 15 years. She covered five main points on building a human connection and making people remember us. Her slides were absolutely beautiful, and I learned after the talk that they were all done by a UX craftsman at 8th Light. The images I’ve put in aren’t the slides she presented, but pulled from a similar talk of hers hosted on YouTube.
Have 5 key points for small talk about yourself that is likely to be relatable. For Margaret, she introduces herself as a mother of 3, working for her son at 8th Light, living in Florida but working in Chicago, a widow, a huge Green Bay Packer (football) fan. So she talks about family, work, travel, tragedy, and sports, and these are points that people can resonate with at least one of them and she can use start building the foundation of a connection with. So think about stories that are yours, that you’re comfortable telling, that people might be able to relate to and like you.
Talk about your work and what you do passionately. Know and be able to communicate the value that you can bring clearly. Be able to show you know what your talking about with making recommendations and talking about previous work you’ve done. But building trust and relationship requires patience and takes many small steps over a long time.
As the talk was for predominantly software developers, Margaret talked about how non-technical people might feel, when developers start talking tech. This is important because chances are, clients are non-technical, because otherwise they wouldn’t be hiring software consultants! So talk about and explain technical terms. Make sure that people in the room who are non-technical, and even those who are non-technical, understand what you’re talking about. It might be helpful to practice talking about a subject to a spouse or friend and work out how to get those concepts and ideas drawn out.
Also, speak up when there are problems or confusion. Ask someone to explain back to you what you’ve just said for a confirmation of mutual understanding, so that you can work on bridging any gaps.
Margaret talked about facing problems head on when encountering turmoil or calling somebody to get a problem fixed without letting it fester. If the problem involves not meeting a commitment with a client, be sure to keep them in the loop and have them know what’s going on every step of the way. Admit your mistakes and apologize. Be sure that your actions speak louder than your words.
Make an effort to stay connected to people – calling, asking to meet up face-to-face, taking someone to lunch or breakfast, and remain fresh in people’s minds. Margaret did this by spending time every single month to sit down and wrote a thank you letter to every single client and prospects. She would also include a chocolate bar and send them to everyone and when she would attend conferences, people would ask her she’s ‘the candy lady’, and that’s how remained memorable and fresh on people’s minds.
Good communicators, live it. They live their lives centering around great communication and maintaining these human connections.
Today is our feature freeze. This means no more adding new features and working only on styling and cleaning up code. Our team is right on schedule and we paired on adding some unit tests to up our test coverage and refactoring code where we see fit.
I’ve been trying to get some fancy input boxes since the beginning of the week, and see this as the perfect window to get that in. Basically, when someone goes to the bunch page and starts to enter addresses into the input boxes after the second one, another input box will automatically slide down and be semi-transparent. This would make a much nicer user experience that is sleeker and more impressive!
My team wasn’t so supportive of me trying to add this styling though. Implementing this styling would definitely break a lot of feature tests since the tests ran by clicking a button to add a new input box, and our entire app was dependent on those input boxes working properly. I understood their concerns, but I knew this was the right thing to do and knew that if someone helped me, we could do this and get everything done, with tests passing, with time to spare tomorrow. But my team didn’t seem too interested in working on this, so I would have to do this on my own if I really wanted it. So I asked if I could figure out how to make it work, if they would be cool with it, and the majority said yes, so I have to get crackalackin’!
In the afternoon, I attended one of the fantastic tech talks that Pivotal Labs hosts every Wednesday. This week’s talk was given by Margaret Pagel on Improving Communication.
After lunch, each team did a rough presentation in front of Alex on our final projects for preliminary feedback. Our team got a rough presentation put together and the basic flow of who does what, in what order. Charlotte will introduce our app, I will narrate a demonstration of how Bunch works, Jeremy will talk about the algorithm and backend of the inner-workings of how we churn out our results, Pete will talk about the various technologies and tools involved in building Bunch, and finally Dave will talk about how we can extend and take Bunch further if we had more time.
Noam commented that Team Bunch is the only team he’s observed that’s always working/”looking super serious” and never plays any ping pong. Hmm.. Interesting.
Charlotte and I got the tabs for different venue categories – Top Picks, Food, Coffee, and Drinks – working. The hardest part about doing this is applying the appropriate style to an ‘active’ tab. So what happens if the computer doesn’t know if the ‘cafes’ should be in the ‘cafe’ tab? You get restaurant/cafe/drinks content going under the default ‘Top Picks’ tab.
Alex is back today!!! <3 I overhear somebody asking “Where is Alex?!?!” at least once a day, every day. We joked about massive lines forming for Alex once he gets back.
So bright and early, first thing in the morning, we made a new list on our team den’s white board of all the miscellaneous things we need to clean up on that didn’t quite fit on Trello, which serves more of a high level overview of separate tasks. Notice our little list of questions saved for Alex on the left:
Also, notice we changed our logo to grapes (on the top) today. The back and forth between grapes and bananas ensues. So, things from Alex that we learned today that we couldn’t figure out for about a week are as follows:
– Images break when we push to Heroku despite showing up fine on our local machine because Heroku adds a little string (for security?) after all the links in HTML image tags, and they probably Heroku wasn’t locating the images with the strings appended properly. So the way to fixed this, is to use Ruby image tags instead of HTML tags and Ruby will take care of things for us. So here’s how we made everything work:
By the end of the day, Dave and Peter got a carousel of images playing in our homepage background. Yay! We’ve been wanting to implement this carousel forever, but our biggest problem was actually not technical, but finding nice, appropriate photos! It turns out that nice, high resolution photos of cafes and pubs are hard to find, and ones with people in them are even harder, because those are almost always paid. Yargh!
Charlotte and I got Foursquare results to show up (uglily) in the sidebar, as well as worked on getting different venue categories into tabs (Top Picks, Food, Coffee, Drinks).
We didn’t quite get around to working on our end goal of having tabs until 5PM. we kept getting sidetracked with fixing broken image links and styling the boxes that venue information show up in instead of making tabs for categories. It was easy enough to get the appropriate venue types loading and showing up when we clicked on the category links, but the most difficult part of making tabs work is setting a tab to being the ‘active’ tab when it’s been clicked on, and having that tab highlighted.
Well, sort of. We get to that tomorrow. Look how much we got done today!
I left at probably an all-time early today because some of my team members were still around (I’m almost always the last to leave) to get some delicious ramen in SoHo. Yum yum!
I planned to go to Camden Market and then Tate Modern, but after I showered, I felt motivated to code and didn’t want to let it slip by, so I went to this wonderful vegetarian cafe called Gallery Cafe near Bethnal Green.
I went there in the morning to avoid my landlord, but I liked it there so much I went back for more in the afternoon!
I redid my Week 4 Takeaway challenge to make it perfect the way Enrique asked for. It felt really good to actually know what I’m doing and be able to do the whole thing from start to finish TDD’ed and with 5 classes!
Check it out on GitHub I don’t plan to be showcasing this, but I just wanted to finally get this done, well. For myself.
We decided to all go to Charlotte’s again, bright and early, at 11am this time so that we’d be able to leave earlier. Pete was probably the only one who showed up on time. I showed up 10 minutes late, Jeremy a bit while after that, and Dave had his mom’s 60th the day before, so he let us all know he’ll get there when he gets here. Classic Dave. Jeremy seemed genuinely frustrated because he didn’t understand why something wasn’t working for the first time in the morning, but he worked it out soon enough before going insane. Noam came by to film us, made us some coffees, and helped us choose a Snazzy Maps theme for our maps page. We went with Pale Dawn.
Some close contenders: Midnight Commander
“The Stride’s One” – Neutral BlueOur team has really spent an unreasonable amount of time choosing the color scheme of our maps page. But despite spending a weird amount of time on choosing our map theme, we still got a lot of other work done and was pretty happy with the amount we got done by the end of the day. We’ve been working on building the backend for getting Foursquare recommendations onto our app, but haven’t gotten to showing the results on the sidebar yet. So one of the main tasks for tomorrow would be to have the recommendations showing instead of having those empty input boxes.
In the afternoon, we got to have amazing salads and sandwiches in Charlotte’s garden and everything was so wonderful. The sun was so nice and the company and food was so good. I wish I got a photo, but Noam has much of it on film. I wonder if it’ll make it into the documentary.
We got around 4 more solid hours of work done after lunch and Jeremy had to go around 6:30pm. Even though we all decided to go to Charlotte’s earlier so that we could leave earlier, we all leave at around the same time we left last time- 7 ~ 7:30 ish. I forgot to take a photo all day until the end:
Dave and I walked to the tube station together and talked about how lucky we felt we were for getting such a great team and being able to get so much work done so swimmingly. We wondered about the other teams’s apps look like and realized that neither of us has really seen what the other teams have been doing. We decided to check their sites out tomorrow. Yay!
I almost flipped the table today!
I spent a long time trying to get a bunch of styling and refactoring done, but when I tried to pull from development to have my copy calibrate with the development version that everyone is working from, I had 3 merge conflicts – the biggest merge conflict I’d ever seen because I’ve been spoiled by everyone being good with frequently pushing and pulling.1
While we still got a lot of work done, but we’ve had the most ever of THREE files having merge conflicts! Merge conflicts happen all the time though – so juniors, don’t think that merge conflicts means somebody did something wrong – they’re just annoying because time must be spent fixing conflicts rather than coding.
Charlotte and Peter paired on integrating the Foursquare API and I made a small contribution by pointing out we don’t need a model for venues during my pop-in as the rover for the day. 2
Jeremy worked by himself on implementing this algorithm based Dijkstra’s Algorithm on the solving the problem of finding the meeting point which produces the least cumulative travel (by driving) for all parties.
I thought it was pretty cool when I saw him scribbling stuff on a piece of paper working out the algorithm for our specific problem and asked to pair with him in working it out, but Jeremy usually doesn’t feel particularly collaborative (I’ve worked with him before) when he wants to work things like this out, so he basically said no. So I tag alongside him when he consulted our coach, Sam, so that he wouldn’t be the only person on the team knowing what’s going on with a pretty integral part of our code. 3
So the algorithm Jeremy worked out was simple enough – because he’s really smart and clearly has a deep understanding to be able to work out a simple/elegant solution that makes sense – and it was basically taking the midpoints of midpoints until the midpoints by travel time (not distance, even though it looks like distance in the following diagrams) become less than 5 minutes, our definition of the equality in travel time:
I made Jeremy promise to pair with me to implement the algorithm on Monday. Hehehe
Building off our great ripoff the of the Airbnb homepage yesterday, Dave presented us with this nice semi-transparent side bar for our site that we all love. I contributed to the look & feel of the site to this:We had some debate about whether the “Add another address…” link should just be a big plus sign or if it should be a text link like the second version. I wonder if other teams are having as many debates about everything as we are. All of this conjecture is quite good though; it means we all care and feel comfortable challenging one another and defending our ideas, which are terrific signs of a healthy and productive team.
- This is essentially, working on and submitting on small, isolated pieces of code that wouldn’t conflict with what other people were working on which they would later push (submit). ↩
- We have an odd number of 5 people, so we have 1 person being a ‘rover’ working on miscellaneous tasks like writing our README file or doing some CSS styling that everyone hates, or research APIs and what not. ↩
- Read: I will find a way get what I want one way or another. ↩