At the time, our high school sports reporters and editors were taking phone calls for sports scores all night, entering them into the pagination system and then occasionally creating HTML tables, which they then pasted into our content management system. If they wanted to update scores online, they would have to regenerate the tables and paste them over the old ones or change things by hand.
In previous projects, I’ve helped build massive backends and admin systems in Django to keep track of sports scores, team rankings, individual players statistics and the like. They are big systems, require upkeep and a steep learning curve for those entering in the data. We didn’t want to add on more complexity to the ever-expanding amount of applications our team works on, so we wanted to figure out another way. And we wanted to simplify data entry for people who are already quite busy.
We pitched building everything as a Flask app that fed off a Google spreadsheet, similar to how our Tarbell project works. We would have a spreadsheet with seven tabs for seven days, with different rows for each of the data points, and then we would generate HTML files we could push to Amazon S3.
First we had to figure out how to store the data. Volleyball games have different scoring systems than track meets, which are different still from football or baseball games. So we had to create some fields for specific sports types and also train the staffers how and when to enter in data in certain cells in the Google spreadsheet.
Then we designed the responsive frontend because people like to check sports scores of other area teams while they’re at the game. Users can look at individual high schools, individual sports or just the latest scores. Again, this was based on conversations about what we thought would best suit the needs of our users and what they were looking for.
The app updates every few minutes, checking to see if anything’s changed in the Google spreadsheet. We download the score data, hash it with md5 and compare that to the most recent hash. If they differ, we know some update of some kind has occurred, so we regenerate all the scores. But most of the time, they’re not different, so we save a lot of CPU cycles. But if anything has changed, it regenerates the pages and pushes them to S3. This helps us to save some money, as we’re not always overwriting existing pages or spending CPU time rebuilding scores based on an unchanged dataset.
Our colleagues on the pagination side have written scripts that download the Google spreadsheet and ingest it into our pagination system, getting updated scores as the night progresses. The application also uploads each day’s scores as JSON and CSV files, which are stored on S3, so our sports staff can go back and use the data — or update it — for any reporting purposes in the future.
Overall, I think it’s a pretty nifty app. Not only does it help present data in a pleasant way for our audience, but it also saves our sports staffers time every night, allowing them to focus on news gathering and not worry as much about presentation.
Say you’re interested in an internship with the Chicago Tribune News Applications team (or, really, anywhere). You see our post on the Tribune Media Group jobs site, or right here on this blog. You respond. We don’t call you in for an interview.
“What went wrong?” you wonder.
Well, any number of things. Maybe nothing. Maybe we just didn’t think you were a good fit.
“But I would have been a great fit!” you wail to the heavens. You shake your fists and rend your garments. And then you ponder, “What could I have done differently that would have at least merited an interview?”
Okay, dry your eyes, get a drink of water, and prepare for some advice. I’ve been handling the annual Search for the Summer Intern for three years and I have thoughts.
First, though, you should know one thing: I want you to have the best possible shot at this (or any other) internship.
I’m not looking to arbitrarily disqualify candidates. I hope that we have more qualified applicants than we can handle—from a totally selfish perspective, options are great! Therefore I have provided the following list of the Five Most Important Things to Do on Your Internship Application:
1. FOLLOW THE DIRECTIONS
Excuse the shouting, but this one piece of advice could stand in for the entire list if necessary. If you neglect to follow instructions in the application process, it seems like you either don’t care enough to pay attention to directions or don’t think the directions apply to you. Either option is a bad message to send.
If, for example, the instructions say (perhaps even in three separate places…) to include a cover letter, you should include a cover letter. If you choose to skip that step, I will choose to skip reading your resume. By not even meeting the basic requirements of the application, you’ve wasted your own time and that of a lovely gentleman in HR—and the only reason you’re not wasting my time as well is that I eventually asked said gentleman to not bother forwarding me any applications missing cover letters.
2. Demonstrate understanding of the role, relevance, and interest
No, the job description probably won’t spell out every duty the internship encompasses, but you should at least be able to figure out what the role broadly entails…and only apply if it’s something you want to do.
Sometimes your experience doesn’t seem like an obvious fit for the role you’re hoping to fill. That ostensible mismatch doesn’t automatically disqualify you from consideration, provided you explain why you’re interested in and think you would be a good fit for the internship. If your resume says you’re in culinary school and your cover letter is a generic copy-and-paste job, I won’t assume you’re learning to code on weekends and are an avid hackathon participant. But maybe you are! Make it explicit.
3. Pay attention to details
One typo isn’t going to disqualify you, even with someone as nitpicky as I am. But if your entire application is riddled with typos? Not good. If your cover letter is obviously copied and pasted and I can see where you’ve forgotten to change some of the relevant details? Also not good. If you get the name of the company or team wrong? Pretty bad. And I would always prefer “Dear News Apps Team” or the old standby, “To Whom It May Concern” over entirely the wrong name. If you’re not sure, don’t just guess.
All of the above come across as sloppy and lazy—you didn’t pay attention the first time and you didn’t look over your work before sending. Those are not traits we want in an intern, particularly one whose role will entail committing code to a live site.
4. Don’t squander opportunities
If for any reason one of my teammates or I do contact you (perhaps a colleague recommended you, or I have reason to suspect some form of technology botched your cover letter), make the most of the opportunity. Theoretically, we’re reaching out because we’re interested in you or want to give you a chance to explain or elaborate. If you’re really interested in the internship, this is the time to put in a little extra effort, not just copy and paste your generic cover letter, typos and all.
5. Follow the directions already!
Yes, it’s *that* important.
Covering elections is a staple in American journalism. I’ve covered elections as a reporter and I’ve helped display election data in drastically different ways at three news organizations.
So first, a little primer on elections data. Generally speaking, on election night, the data for vote totals is tabulated by county boards of election and then sent to a state-level board. Next, the data is harvested by vendors such as Ipsos and the Associated Press. Until recently, the only nationwide election data vendor for news organizations was the AP. While other data vendors exist, they usually focus on more niche markets, such as campaigns and political parties.
The AP has a physical person in every U.S. county to report back to them what the current vote totals are for different races. It’s incredibly costly, but means you can dive deep into trends in data. The AP has a system that lets you FTP in and download the data in XML or CSV format, which your publication can then display.
The AP doesn’t always get state, county or local-level election data in this same manner. Thankfully, most states (and some counties) have online data portals, RSS feeds or APIs that can be downloaded, scraped or accessed to get the data you’re looking for. In some places, though, a real person has to sit in an election board’s offices and get the election data back to the news organization somehow, typically by calling or emailing.
While displaying data online may get a lot of attention these days, remember that many news organizations still print something every day. So news organizations have also needed to solve the problem of importing AP election data into their print editions, too — generally through decades-old pagination systems.
Now let’s talk about the differences between the three places I’ve wrangled election data for.
The New York Times Regional Media Group’s Election Data
In 2010, I was a newbie developer at the now-renamed The New York Times Regional Media Group. I started a few weeks before the 2010 midterm elections. My new coworkers had already built a system to FTP into the AP, import the data into a MySQL database and then display it on our 14 news websites using iframes hitting tables built in PHP.
I helped by load-testing, or seeing how much traffic the project could take, while we were running importation tests of the AP’s test data runs. By my estimations using Siege, I thought we were in the clear, with 2,500 hits a minute not crippling anything. If election night traffic had indeed been 2,500 hits a minute, we might have been in the clear. We were not.
If memory serves, we had one EC2 medium instance running to import and display the data and a medium MySQL instance running for the database. I didn’t know about caching and thought it was just something that was turned on automatically. It wasn’t.
On election night, we had two newspapers who received election data first, and things ran smoothly with them, as they were in smaller markets. Then the Florida papers started getting heavy traffic. Our EC2 instances became bottlenecked, stuck at 99 percent CPU usage, unable to read the AP data, let alone write it to the database with updates.
This brought all 14 of the newspaper websites to a crawl because these iframes were getting loaded before almost anything else on the page. In the end, homepage editors took the iframes off the pages, a coworker wrote some SQL to hand-optimize the election tables and, by then, traffic to the sites had subsided to reasonable levels.
It was the scariest night of my professional life. Thankfully, most of the newspapers were happy, as they hadn’t ever even attempted to display live election data on their websites, so this was still an improvement for them. And I learned to set up caching — in later cases, Varnish — when attempting to hit a live database in any way.
The Boston Globe’s Election Data
Next, I was at the Boston Globe during the 2012 general primaries. As then-hopeful Mitt Romney was the former governor of Massachusetts, the Boston Globe was a major source for news and coverage of the GOP primary battle. And the New Hampshire primaries were that paper’s bread and butter.
But the team I worked on had a fun logistical problem: We needed to display the data on two websites, Boston.com and the newly-launched BostonGlobe.com. Each ran in a different content management system, each had different styles and each wanted the data displayed a little differently.
The first problem we had to solve was how to pull in the data. The Boston Globe’s CMS was Methode, which stored everything — stories, photos, etc. — as pieces of content in XML. As the AP already provided data in an XML format, we would just need to import it, change some of the tags to better suit the Methode ingestion system and then I would write the code necessary to display the data.
Thankfully, the Boston Globe’s systems staff figured out quickly how to go in and download the XML data and put it into a spot in the CMS that I could access. We had created mockups and styles for displaying the data responsively — still a new concept at the time — and now had to pull in the data, via some incredibly ugly Java I wrote.
We didn’t have time to do something similar with the Boston.com CMS, which was at the time, I believe, going on 12 years old, and was somewhat fragile. So we decided to build separate styles and templates in BostonGlobe.com that would could iframe into Boston.com. Not the best way to do things, but it’s how we did it.
And then, as the primaries started happening more and more frequently, I would have to make each primary its own chunk of code, violating the DRY principle repeatedly, and just trying to get everything deployed to production in time for the producers to be able to slot the items on the various homepages.
Another coworker had an old Python script that just created basic HTML tables for county/town election totals and pushed them into Boston.com, for a more in-depth look. Lots of moving parts, different content management systems, different styles, a lot of work for the small number of people working on it.
The Chicago Tribune Way(s)
Now I’m at the Chicago Tribune. In 2012, my coworkers built a system that pulled in AP election data into a Django site with Varnish in front for caching. For local races, they pulled data entered by Chicago Tribune staffers into Google spreadsheets based off information gleaned from various county board of election sites, which were then turned into flat files as well. And then the AP data was pulled into our pagination system for the print product through tables the AP sent, just like it had been done in previous elections.
Fast forward to a month ago. The Chicago Tribune no longer subscribes to the Associated Press, but Reuters has entered the election data game. Instead of having to FTP and download XML files, we hit an API and receive JSON. It’s pretty nifty and much more conducive to building web-facing applications.
We wrote a Python wrapper to hit the Reuters API and reformat the data for our purposes, and then we again built flat pages based on that data, using Django Medusa. And for local elections and referenda that Reuters wasn’t covering, we again had Tribune staffers entering data into Google spreadsheets.
We still had to write a custom system that takes the Reuters and Google spreadsheet data and sends it to our pagination system. This required us figuring out how the data needed to look — basically a mix of XML-ish template tags and tables — and then FTPing it to an area where our pagination system could ingest the files, give them proper templating and allow page designers to put them on pages.
So what have I learned?
Elections are big events traffic-wise, and static sites take large traffic pretty well. With the Boston Globe and Chicago Tribune solutions of using basically static sites (XML and sites baked to S3), it meant little freaking out at 9 p.m. when you’re getting thousands of pageviews a second. If you’re having to deal with lots of calls to your database while it’s also reading and writing, you’re going to have a bad time. Static sites are wicked great.
Testing is important, but knowing what to test is more important. At The New York Times Regional Media Group, I thought I knew what I was doing, but I was testing for unrealistically low traffic and didn’t think about what would happen while it was trying to write election data to the database, too. I now know I could have asked folks on the NICAR listserv for help, or tweeted questions or really just asked anyone with a few years of experience, “Hey, will this work?”
Election nights are stressful, so be cheerful and smiley. We at team Trib Apps try to be cheerful and kind whenever working with anyone, but with this many moving parts, it never hurts to just think “smile while saying words” when conversing with other folks. We’re all working hard on these nights, and I’m a big fan of not adding any extra stress on people’s lives. That’s also part of what our technology is supposed to do — make things easier for folks in the newsroom.
Have a point person from the tech side to coordinate with the newsroom. When local election data started coming in, I stood in the area where folks were entering it into Google spreadsheets, just so someone was around to help answer any questions on the spot, while David Eads, who was the lead developer on the elections project, made sure the technical side was running smoothly. We had only one minor hiccup that was quickly fixed and we were able to identify it because we were all near one another, able to communicate more effectively. Even though we work with machines, this job is mostly about communication between humans.
Know that you’re going to be covering an election again and make your code reusable. When we were writing our code for the primary, we knew a general was coming up in November. We also knew that other Tribune newspapers would be itching to show election results so we needed to get the fundamentals right the first time.
We would love to hear about your experiences with election data. Please feel free to add a comment and tell us your story.
Distraction is 9/10ths of the Internet, right? Liberté, fraternité and doge. So of course, it’s nice that text-editors ship with “distraction free-modes.” It’s nice that certain kinds of technology problems command the kind of focus that could block out a hurricane.
And yet. Talking about what’s going on in the world is part of journalism. It’s a requirement. An uninformed journalist is a very, very hungry one. “Hey, did you hear about this, what do you think of that, here’s the link.” It’s the water we swim in.
And to be honest, these two aspects of work on the News Apps team really complement each other. We solve problems and carry on conversations through our computers as a way of life, taking breaks from one to be rejuvenated by the other.
So, rather than be selfish and NOT share with you some of the wonderful things we’ve discussed on the side, I’ve decided to use this post for the greater good of all, and present them below. As a listicle. A listicle for good. Not evil.
1. “Hey, so, all of you have minds. If you enjoy exploding them while learning new things and staring at pictures, boy do I have a link for you.”
2. “I’m going to just ask her, it’s a data visualization of conservative and liberal hashtags on Twitter and how separated the two sides are – almost no overlap.”
3. “Until I meet a wysiwyg editor that can do everything I can do by hand, I’m not going to believe you.”
4. “THAT CANNOT BE REAL”
5. “‘We also can not take your money – money that you earned with your brain, knowing that taxes will be used to provide weapon for criminal group that will use it against you or to build prisons where you will be held for stating your civic position.'” -posted by the PyCon Ukraine organizers
6. “‘Want your name removed? It’s all public information, and we didn’t need your permission to build a website and put public information on it, but we do have a policy.'”
7. “Actually, here’s a way to make it without sous-vide (and wow, those brussels sprouts sound amazing):”
8. “Thanks to moving, I now know how to dispose of leftover latex paint safely.”
9. “I never want to walk like a regular human being again.”
10. Needs no explanation.
And, finally, this one goes to 11.
And now, back to work.
Sometimes, you get an idea so good you can’t wait for Monday to code it up and show your friends. (If you’re reading this, you have weird friends.) You tell yourself the idea is simple, pretty straightforward to implement and you have some time on Sunday afternoon for a fun project. Maybe you just want to get a prototype built to explore the idea, confirm it makes sense, demo it for your boss and team members. After building a few of these, you find yourself repeating common mistakes, coding yourself into the same corners over and over again. But it doesn’t have to be that way.
If you’re like me, your hard drive is littered with folders bearing now-obscure names, the tombstones of weekend hack projects that never came to fruition. Which is fine: most ideas are bad and most weekend hacks won’t go anywhere. But this post is for the ones that make it past the haze of beer and sleep deprivation to actually become something real. I have two pieces of advice, seemingly contradictory, that will make your projects better and help you enjoy them more.
The first and most important thing I’ve learned is that it’s always worth doing it right the first time. The old carpenters’ adage applies to the craft of software: measure twice, cut once. By writing code correctly when you first get started, you make it so much easier to maintain later. Generalize that set of lines you copy-pasted 3 times with slightly different variable names! Decompose that hundred-line function into smaller pieces you can reuse elsewhere! Take five seconds and write a comment explaining why that magic variable has to be set to 11 when the code first runs – you’ll be glad you did when you come back to it weeks later while tracking down a bug.
The reality is that not only does it rarely take that long to write clean code, it only gets easier and faster the more you do it. If you’re working on a passion project over the weekend, use the time to instill good habits that you’ll be happy to have later on. I know it’s easy to just copy-paste an answer from StackOverflow and be done with it, but take an extra few seconds – that’s really all it’ll take – to clean it up, harmonize the variable names and indentation levels and write a comment or two. The amount of time you’ll spend reading this code looking for bugs probably dwarfs the amount of time it takes to tap out a 10-word comment, and that comment could be a lifesaver later on.
That said, don’t worry about the boilerplate. When you have an idea and can’t wait to get started, it’s easy to lose momentum by dragging yourself through the muck of creating the right folders, installing libraries you won’t need until way later, and getting hung up on command-line syntax.
If you’re working on a weekend, or for fun, you have the freedom to explore what interests you. You’re not required to eat your vegetables before you get to dessert; it’s a Sunday! Start with the cake, and eat the carrots if there’s time.
Let’s say you want to learn the Twitter API, and you have an idea for a bot that tweets rugby scores. You can start by just trying to write code that sends a tweet. Then focus on the gritty scraper you’ve got to write in order to get the rugby data. That scraper is gonna be a huge pain, filled with corner cases and unexpected gotchas, and generally not that much fun to write. You might think you need it first – your tweets need data! – but spending an hour sucking down data and parsing it before you even get to the thing you actually wanted to do in the first place is just going to demoralize you. The energy you had when you first got started is valuable; don’t waste it on boilerplate code.
Those two points may seem contradictory, but they really boil down to the same thing: don’t be afraid to take a step back and prioritize. What are you trying to accomplish and what will help you keep your momentum going? Some tradeoffs are worth it – take the five seconds to document your weirdest code – but some tradeoffs don’t make sense. That scraper can wait.
Finally, don’t try to get it all done at once. Know how to tell when you’re at a good stopping point: when you’ve captured the basic idea you were trying to implement; when you’re about to start going down a rabbit hole of documentation for a new library; or when you just need to take care of a bunch of special one-off situations that you think won’t take that long, but inevitably suck up endless hours. Write up a bunch of notes to yourself in the comments, try to transcribe everything that’s currently stuck in your head, make explicit all the next steps you’ve got mentally planned out. You won’t remember them in the morning, because now the sun is coming up and you’re going to step back, go for a walk and try not to get burned out. You still have to show your coworkers the beautiful demo that, mere hours ago, was just a gleam in your eye.
Don’t let the stereotypically laid-back atmosphere at technology firms fool you, because being a web developer is stupidly hard work. At least it is for us normal folks who have problems with abstract concepts like fundamental math and remembering hotkeys.
In fact, I don’t think it’s unreasonable to say programming is like the Contra of careers. Fortunately, much like Contra, it’s also really easy to
cheat give yourself an advantage.
So hold onto your seats, because I’m about to blow your mind. That advantage? Taking really awesome notes. Boom. How is your mind? Blown to bits? Thought so.
I know what you’re thinking. Take notes? That’s your amazing advice? But just trust me. When I joined the News Apps team, I was a self-taught developer with only front-end web development experience. I had to start learning programming languages, and to do that, I had to take notes.
The idea behind taking good notes is a simple one, but sometimes it’s helpful to be reminded of those simple things, especially when you’re dealing with really complex problems you don’t totally understand. Well, soon after I started with News Apps, Ryan Mark reminded me. I got into the habit of taking really detailed notes every day thanks to his advice. Of all the awesome advice our fearless leader has given me over the past couple years, this has proved to be the most valuable.
Of course, if you’re just starting out with programming, it’s only natural for your programming notes to be terrible. (In one of my early notes, I literally told myself to take better notes next time. Thanks for nothing, Past Ryan.) That’s because, as Alex Bordens mentioned more eloquently in his recent post, sometimes you’re going to have to do things you don’t totally understand. It’s scary but it might just be the only way to learn. Most of the time you don’t break things anyway. Most of the time.
When you do break something, that’s also where Alex’s advice of crying or drinking a beer comes into the fold. Emotional outbursts and alcoholic beverages are a natural part of programming, and I’ve had more than my fair share of frustrating days. But I’ve also avoided exponentially more frustrating days by having really detailed notes as a reference.
All told, I’ve got about five documents on file containing over 33,300 words (not including links). That’s a lot of words, so if you’re going to be a programmer for an extended period of time, or–heaven forbid–make a career of it, it’s a good idea to have a method to the madness.
First, I have a file dedicated to the majority of commands I’ve run on the command line, along with a description of what each does. It’s a pretty straightforward file that acts as a handy cheat sheet when I need it.
Then I have a file full of all of the fancy links that are shared in our group’s tech chat. This includes everything from cool tutorials to posts on interesting new tech. If you can, find yourself a good group of nerds who will share these things with you. You’ll stay on top of your tech, and even if you don’t understand some of it now, it could help you learn something new in the future.
My final set of files are my most important–they’re what I refer to as my daily diaries. These are files where I record what interesting things I did or learned in that day, as well as share my innermost secrets about all the cute boys at work. I record by date so I can match tasks I’ve completed to changes in our Unfuddle tracking system (and to my own recollection). For example, I’ll vaguely recall doing some work on a particular project last fall; since I’m recording by date, I know what section of my notes to check first if I need to reference that work again.
I put commands and particularly relevant chunks of code in bold, so they’re easier to spot as I scroll through the abhorrently long files. The writing is keyword rich for the same obvious reason (CTRL+F is the best). I take entire error strings I received and paste them into the file; if I come across this error message again, I can easily find it in my notes and see how I fixed it, before having to resort to Google and wading through Stack Overflow threads for solutions that might not even apply to me.
Most importantly, I put a little bit of pressure on myself to record notes each day and not slack off, even if I try to convince myself I “mostly understand” everything I did that day. It makes it more of a ritual and part of my standard workday.
I know this all sounds very simple, but trust me when I say that you’re going to need all the help you can get as you start programming. Taking good notes is paramount to your success, otherwise you’re going to be asking your nerd friends/coworkers way too many questions and, unless you funnel constant streams of coffee into them, they’re likely to get agitated with you.
Take notes. Don’t agitate the nerds.
First, the internet is hard and will likely make you either cry or drink heavily depending on your personality. That’s OK. It’s why you have friends. Stackoverflow, GitHub, Google and David Eads are all readily available when it’s 1 a.m. and you just broke something. I also suggest an SOS on Twitter.
Second, you already have a lot to bring to the internet besides your novice programming skills, even if it doesn’t seem that way. If you take nothing away from this article besides this point, I’m going to call it a win. No matter what your discipline, you already have a unique set of skills that apply to the web. You just need to figure out how to apply it right away while you learn to code. Trust me, it will help your confidence and growth. If you are a designer, you know how to organize information. That is something the internet needs. If you are an editor, you know how to manage a project and make sure no one forgot the ‘l’ in public. That is something the internet needs. See where I’m going with this? You’ll be surprised by how much you can already do.
Now that we have that out of the way, in no particular order:
The only way you will learn is by doing. How do you get to Carnegie Hall? Practice! You will write lots of code and most of it will be crappy and broken. That’s OK. Cry it out or drink a beer, then move on. The more you write the better you’ll get. Repeat after me: “The more you write the better you’ll get.” Find a project that starts with your idea then make it a real thing online. When you make something work the first time it will feel like performing a miracle and the internets will love you for it.
Plan on working more. You have to put in the time unless you are a natural and the only reason you’re reading this is because my words are simply that captivating. Plan on coming in early, staying late and working on your own time. You may not always be in the classroom but you should always be learning. It will be a lot of work, but learning to code should be exciting.
Adjust your workflow. Break away from your print-centric processes. It’s easy to design your project with your favorite Adobe product, but I can tell you right now it’s going to hurt you. While it’s important to have a plan/sketches, you will ultimately spend more time than necessary trying to make your website mockup perfect. Remember, mockups rarely translate identically to the final product. Instead use a simple web sketchup tool like balsamiq or a pencil and paper. If your Stockholm Syndrome just won’t let you ditch Adobe, then simplify your process to use generic squares and remember it doesn’t have to be perfect.
Don’t cheat your audience. This is a particularly important point to keep in mind if you are developing on deadline. Know your abilities and what you can deliver. As journalists, we are here to tell clear stories. Shipping a half-baked, broken website doesn’t serve your readers. Look for solutions that fit what you can deliver and put you in a position to succeed. Don’t shy away from something hard because it’s hard. Just make sure it’s the right way to tell the story.
Don’t be afraid to be a fraud. When you first start writing code you certainly won’t know everything and the people around you will know a lot. So when someone starts describing technology with a bunch of acronyms that sound more like STDs than internet, just roll with it. Ask questions, but remember you can solve problems on your own. Pay attention to the point the person is trying to make then go back to your desk and Google the bejesus out of those acronyms. It’s normal to fake it till you make it. And sometimes you may never think that you made it.
The internet is hard. Don’t let it deter you. It’s hard for everyone. It’s hard to learn a new language or change your workflow or scale back your ideas or spend less time watching House of Cards, but it’s up to you to make that sacrifice if you want to evolve.