Well, the good news: a Confluence page exists to inform CIA software engineers not to put binary files in their git repos. The bad news? They put binary files in their git repos! OMG. Images? Yuck. Word documents? Wat. PDFs? Please, no! SDKs. You’re kidding.

2. The CIA uses Confluence to store code!

“You should put source files in Stash!” says embarrassed [User #524297]. Correct! You shouldn’t be storing code inside a documentation tool, folks. Let’s put this stuff in version control where we can code review our work!

3. The CIA doesn’t code review!

How many datas and idxs does it take to make a url. So much sad panda here:

data = self.request.recv(65536).strip()

data = fff.dcode(data)

idx = data.index(“\n”)

headers = data[idx+1:]

domain = data[1:51].strip()

port = data[51:61].strip()

data = data[62:].strip()

idx = data.index(‘ ‘)

operation = data[0:idx].strip()

data = data[idx+1:]

idx = data.index(‘ ‘)

url = data[0:idx].strip()

4. The CIA doesn’t escalate when blocked. :(

The CIA software engineers take their roles as secret-keepers extremely seriously. They take it so seriously they keep it a secret when they are blocked from completing their work. And, there’s also a note about product intent drifting based on decisions made by the engineers but I’m going to move on….

5. The CIA documents its problem solving patterns and uses “techniques” to do it!

Switching gears, this one is actually pretty awesome and I’d love to learn more. When creating a brand new confluence page for a project, they default to include a “technique” section on each page. Each of these techniques links out to pages describing patterns others have used to solve similar problems. It’s essentially an attempt at creating building blocks of patterns so that others can use these to solve future problems.

But again, put this code in Stash. Get it off Confluence, CIA! You can do better! I believe in you!

5 Astonishing Revelations From Wikileaks Vault 7 Release was originally published in The Rime of the Digital Mariner on Medium, where people are continuing the conversation by highlighting and responding to this story.

#2 You’ve created a killer presentation.

#3 You’ve practiced.

#4 You’ve rehearsed in front of a friend.

#5 You’ve worked out the kinks.

#6 You showed up on time.

#7 You’re a little nervous.

#8 But you have courage!

#9 And you feel awesome!

#10 So, let’s present!

If you liked this, would you mind clicking the ❤ button below so that others can find it. Thank you!

You may also like reading Stop Whiteboarding or The Myth Of The Unlimited Vacation Policy.

10 Signs You’re Going To Give An Amazing Presentation 100% Of The Time! was originally published in The Rime of the Digital Mariner on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are so many health benefits to taking vacations or staycations it’s a wonder why Americans still don’t take as many as other parts of the world. We all have our reasons for not doing so. Financial situations certainly inhibit it. Hourly workers usually don’t get paid for vacation days. Kids in school make scheduling a challenge. We only get so many vacation days a year. Wait a second. You, CEO-person, can fix that. Institute an unlimited vacation policy!

You’ve heard of them, right? It’s the amazing company perk allowing employees to take paid time off whenever employees want. Want to go on a week-long cruise? Unlimited vacation policy! Want to take a month to learn how to sail a boat? Unlimited vacation policy! Want to spend a quarter of the year searching for lost treasure on the coast of Lilliput? Unlimited vacation policy!

It’s an unbelievable benefit. You can take unlimited vacation!

When I was at Gilt Groupe, we had an unlimited vacation policy or, more specifically, a no vacation policy policy. The origins of the policy are unknown but one rumor traced its ancestral roots to management not wanting to track vacation days. An unlimited vacation policy is certainly better than its estranged and annoying cousin, no vacation policy. But, did it do all the things vacations are supposed to do when we say vacations are healthy?

It worked for recruiting. The aspirational possibility of not having constraints around vacation days was an easy pitch to candidates.

But once a candidate became an employee, the benefits attached to vacation days got complicated. The policy inspired flexibility, less bureaucracy, and trustworthiness. But in a straw poll, we found we were taking less vacation days than our friends in similar positions at similar companies that had stated vacation policies. Why weren’t we taking unlimited vacation?

1. We took as much vacation as our peers and our leadership. If your manager took one week of vacation a year, you were unlikely to take three weeks of vacation.
2. The less aggressive you were, the less likely you were to ask your boss for vacation time.
3. If someone was aggressive enough to ask for three weeks continuous vacation, their boss didn’t have support to push back if needed. The boss would look appear as a jerk if she declined the request.
4. We wasted so much time talking about vacation time.

A lot of the problems surfaced as a result of not having a policy that managed expectations for both the managers and the direct reports. It pinned managers and direct reports against each other. And, it resulted in bad conversations about whether people deserved to take vacations. It just didn’t feel good.

When I started managing at Gilt, I instituted a rule that everyone reporting to me had to take one week of vacation every quarter. I realized some people were unlikely to ask for vacations because it wasn’t clear what the expectations were. Since an unlimited vacation policy is up to interpretation, I made my own interpretation and instituted it so everyone felt like they had fair ownership over their health and well-being.

So, you have to track vacation days. And, I think you should make sure your employees take vacation every year.

Which leads me to my current belief that my ideal vacation policy would be a vacation policy range. The minimum is the smallest number of days you must take in a year, because it’s good for your health. And the maximum is the most you are allowed to take, because it’s important you contribute to the organization. You must take any number of days between the range.

Don’t get me wrong. I would still love to take three months off to search for Lilliput. But I think I’d be happier knowing my employees are going to be able to deliver their best work. And, I’d certainly be happy knowing I would have time available to read Gulliver’s Travels.

Hey! If you found this piece to be recommend-worthy, would you mind clicking the ❤ button below so that others can find it. Thank you!

If you liked this piece, you may also like reading Stop Whiteboarding.

The Myth Of The Unlimited Vacation Policy was originally published in The Rime of the Digital Mariner on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2015, everyone should code. That’s a little ambitious. OK. In 2025, I hope that the majority of the world has the chance to program computers. Code is the foundation for startups, tech companies, and the tools that everyone uses on a daily basis. It’s important we all know how it works. Although we are years away from a world in which the majority of the population programs, I think everyone at your startup needs to know about code today.

YSOLO

Your Startup Only Lives Once

You’ve been hired by super-cool-stealthy-funded startup Format Corporation to lead all of their marketing efforts. Congratulations! You’ve earned this. All your passion, leadership, and knowledge is going to make Format Corporation known to everyone in the world.

Your first task is to change all of the copy on the website. You rewrote everything. It’s totally witty and brilliant and now it’s ready to ship. Next step: coordinate your request with the engineer’s schedule.

Wat. Wait, no. Come on, now.

You go into the code and make the changes yourself! Your startup doesn’t have time to wait for the engineers. And, your engineers have to focus on significant architectural challenges to prepare for millions of people using your app. You identify where the previous copy was in the repository and swap it with your new poetic lines.

Your startup only lives once and your coding skills mean that you get to actively contribute to its success.

I Can Has Code, Too

Common Language Of Communication

ChopperShot App asked you to be their product owner so that new features can be rolled out to its tens of thousands of users. You’ve got a laundry list of ideas that you cannot wait to have developed. Your goal is the front page of Hacker News and you’ve got the strategy to make that happen.

You realize that 90% of the people who land on your registration page leave without having registered. There is a huge opportunity to change the website’s experience so more visitors convert into users.

You ask the engineers if there is something wrong with the registration page. You wait for their response.

Wat. Oh jeez. No, please, no.

With your programming knowledge, you suspect that there might be a bug that is preventing users from successfully registering for the app. You investigate your application performance monitor and realize that your thoughts were correct. There are errors everywhere. You fire up your browser and try to replicate the problem based on a hypothesis that there might be a client-side issue. Sure enough, your ability to think through the problem allows you to identify the issue.

Instead of asking the engineers why the conversion rate is so low, you tell them that your troubleshooting skills allowed you to identify a problem. Your understanding of how code works on the web allowed you to replicate an issue and to communicate it effectively to the engineers.

NFOMO

No Fear Of Missing Out

You want to work in startups because everyone wants to work in startups! As the HR department and community evangelist for Thankful Dolphin Space Exploration, you make sure the employees and the customers are happy. Your enthusiasm for great work culture gives you a significant edge and you’re going to attract lots of great technologists.

One of your big initiatives is to host a series of meetups at your office. Your employees are going to give presentations and become more confident speakers over time. The greater tech community is going to see Thankful Dolphin Space Exploration as an interesting place to work where people solve challenging problems.

An engineering colleague was so excited by this initiative that she created a branch on one of the repositories where she started building a community calendar. You wonder how the project is coming along and so you ask the engineer every couple hours about the status.

Wat. Oh not this again….

You’re not scared of code and you know how to read a README file. You follow the instructions and quickly spin up the repository on your local machine. You switch to the branch your colleague is working on and observe the latest status. Every few hours, you pull the latest changes to your repository and see what’s been updated. With your ability to spin up the calendar locally, you can provide up-to-date feedback to your colleague without bugging her too often.

Plus, you get all of your colleagues jokes!

You don’t need to be an expert. You don’t need to spend eight hours a day coding. You don’t even need twenty years of experience. But, you’re going to be a much more valuable employee to your startup if you understand the basic foundation on which your company is built.

Same goes for you, engineers. Learn what your other colleagues do.

Everyone At Your Startup Needs To Code was originally published in The Rime of the Digital Mariner on Medium, where people are continuing the conversation by highlighting and responding to this story.

The phrase meeting-free culture is frequently spoken in the same sentence as other empty, feckless phrases like its brother work-life balance, its sister flexible work arrangement, and its estranged creepy uncle synergistically aligned. These words are meaningful only after evidence surfaces as to the way a company operates, not how it wants to operate. A company can’t be meeting-free unless it doesn’t have meetings. And, creating a meeting-free culture is easy! Simply,

Decline all the meetings!

Cool! Finished!

Alas, we can’t.

If your job is to manage others or to convince people to sign contracts, you must take meetings. If your job is to make things or complete tasks, you must take meetings to decide what you’re working on.

So if the meeting-free culture is a dream, what is our reality? As Paul Graham wrote, makers and managers have different schedules. Makers need continuous periods of uninterrupted concentration whereas managers move from conversation to conversation. Instead of trying to eliminate meetings completely, why don’t we try a different strategy that allows us to manage our meetings more efficiently for our work styles.

Here are ten work hacks I’ve experimented with over the past year that have allowed for a more managed-meeting schedule:

1. No meetings after lunch

Manage when your meetings occur. With one of my teams, we agreed to no meetings after lunch. Each team member blocked off her calendar every day going forward. All of the recurring afternoon meetings were moved to the morning and external colleagues were notified of our initiative. This guaranteed separate meeting and focus portions of the day.

2. No meetings without defined goals

What is the goal? If you receive a meeting invite and do not know the context, there’s a good chance the meeting doesn’t have to happen at all. Always request an agenda, regardless of length, so you have context of the meeting. Each agenda should answer one question: what do we need to achieve during this meeting to call it a success? If you don’t know, you should ask.

3. Email first. If email doesn’t suffice, agree to the meeting

Sometimes people set up meetings because of habit. If you see an agenda that you think can be resolved over email, respond to the invite. You’d be surprised how many meetings get cancelled via email. But if there’s a lot of confusion or back and forth emails, a meeting might be more efficient.

4. 20 minute meetings

Don’t accept the 30 minute default the calendar software gives you. Why does every meeting have to be in 30 minute increments? How many times have we been in meetings that ended early and then dragged on because they were scheduled for too long a period of time? Take back your time and question whether the meeting length can be shortened.

5. Don’t make it too easy to set up meetings

This idea is counterintuitive at first but hear me out: if it’s cumbersome to set up meetings, you’ll end up with less meetings. Imagine a situation where every meeting has to be cleared by a meeting czar. This extra step would be just annoying enough to make people question whether a meeting is warranted in the first place. If it’s important enough to make it through the meeting czar, it’s more likely to be an important meeting.

6. Ban impromptu meeting requests

You’ve seen these people in the wild. They roam around when a meeting happens to end early. They’ll tap you on the shoulder and ask if you have a minute to chat. But, don’t be fooled. In their vernacular, “a minute” means “lots and lots of your time.” Don’t allow these types of meeting requests, unless they are emergencies.

7. Phone conference calls need video

They’re all like that. It’s terrible. If you can’t get a video conference, don’t hold the meeting.

8. Decline meetings

Do you really have to attend that meeting? Are you essential to it? Is your life going to change if you don’t attend? Unless you need to attend, don’t. No FoMO. Also, a meeting should not be held unless the correct people are attending. How many times have we be in meetings where we realized that we couldn’t make a decision because key people were not there? Decline these meetings.

9. Emergencies only

Set your schedule so you are always ready to take a meeting in the event of an emergency. If people trust that you are available in moments of crisis, they will trust you more when you say you cannot attend meetings due to your work schedule demanding more time to focus. But when it comes to a high alert, make yourself available.

10. Think of your direct reports

You, as a leader, need to set an example. If you schedule meetings because it helps you complete your work, make sure you are not harming your direct reports’ schedules. If you don’t understand the schedules that work best for your employees, you need to learn what works best for them. At a minimum, read about the differences between makers and managers. You might be harming your employees’ productivity at the expense of your own scheduling preferences. If you’re unsure, don’t schedule the meeting.

10 Hacks for Fewer Meetings was originally published in The Rime of the Digital Mariner on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Interview

There’s a whiteboard in your future.

You’re nervous. You’ve wanted a new opportunity for some time and you’ve convinced a company to interview you. You’re putting too much pressure on yourself because you don’t want to ruin it. You’re capable. You’ve been programming computers for a while now. You like talking about this stuff. You like thinking about this stuff. You like meeting people who know more than you do about this stuff. But, you’re still worried.

Why?

You’re worried because you have a short period of time in which you can communicate your competence and passion to a complete stranger. You don’t know what questions will be asked but you do know you will have to answer them elegantly and efficiently. You have to win over this stranger because he is going to be either a brick wall or your bridge.

“Thanks for interviewing with us today,” a man wearing a gingham shirt, jeans, and black rimmed glasses says as you enter a sterile white room. He sits at a table with nothing before him but a green dry-erase marker. “Two of my colleagues will be joining us in a few minutes but I think we can get started. I’d like you to whiteboard an answer to the following prompt: given a string, write a program in any language you want that reverses the string.”

When did whiteboard become a verb?, you think to yourself as you grab the marker and stand before the empty board of fate. You write your code and your interviewer asks you questions as you evolve your answer. Eventually, time will prevent you from proceeding any further and your interview will end.

The Intent & History

According to one version of history, the whiteboard was created in the late 1950s by a photographer named Martin Heit who realized that he could write on his negatives with a marker pen that could be easily erased afterwards.

A second version reads that the whiteboard was created by in early 1960 Albert Stallion who believed that enameled steel could replace chalkboards. A third version of the whiteboard’s history is that Edsger Dijkstra invented the wall-hanging as a means for screening front-end web developers for the University of Texas Austin’s Department of Engineering’s internal website’s social calendar.

In 1975, Jerry Woolf created the whiteboard pen. And in the 1990s, the whiteboards grew to ubiquity after being marketed as alternatives to the dust caused by chalkboards. Today, the whiteboard is everywhere.

Since the whiteboard was only created in the late 20th century, we can rationally conclude that software engineers were not adequately interviewed prior to this. How could a hiring manager whiteboard someone without an adequate board that is of a white color on which to do so? And yet shockingly, software engineers were actually screened and hired before the advent of the whiteboard. And further, some of these screened-without-a-whiteboard-engineers were actually pretty good.

But it’s difficult to think about interviewing a potential candidate without a whiteboard. It’s how we were hired and as a result, it’s how we hire others. In most organizations, there is no training or investment in how interviews are conducted. We don’t think about it that much because we know it to be a simple tool to assess a candidate’s abilities in four specific areas:

1. Communication and collaboration skills
2. Job-specific knowledge
3. Survival abilities when under pressure
4. White-boarding skills

Outside Software Engineering

How does America hire welders? We now work for a construction company. In our new role, we have to hire some welders for our team.

The welders will be responsible for fusing metals for a series of new projects. They must have specific skills and they must be very talented because they will be working on critical parts of our infrastructure. So, how will we go about screening the welders to see if they have what it takes to work on our projects?

We whiteboard them, of course!

In the United States, the American Welding Society (AWS) certifies welders in a variety of different areas. There are certificates for structural steel, structural aluminum, bridge welding, railroad, aerospace, pipeline, and more. The AWS created these areas of certification in order to provide confidence for a welder and the welder’s employers. Welding is a dangerous, safety-critical profession that is a part of the fabric of modern industrialized living. Bad welds have catastrophic consequences.

But, companies don’t stop the interview process upon receipt of a welding certification. When screening a welder, hiring managers ask the candidate to weld. The candidate must showcase her skills.

Why? Shouldn’t the welder’s years of experience qualify her enough?

Seeing a welding certificate inspires confidence that a candidate can successfully pass a test. Like IT certificates, welders complain about holes in current welding certifications. Listening to the candidate speak about welding gives further confidence that the candidate can retain knowledge about the field. But, observing the welding process gives us confidence that the welder can do the job.

Welding has some parallels to software engineering in that both disciplines appear at face value to have an easy solution for evaluating a candidate: execute a task. The welder welds. The software engineer writes code. And as a hiring committee, we base our decision of the candidate based on the output. But like software engineering interviews, welders often are asked to answer questions that do not relate to the anticipated daily tasks for which they are interviewing:

If the daily task is welding on the edge of a razor blade, then that is what the test should be. — Jody Collier, weldingtipsandtricks.com

Don’t Hate The Whiteboard, Hate The Questions

The problem in software engineering interviews isn’t the act of writing on a whiteboard; it’s the questions being asked.

In general, we need to ask questions of software engineers. That can’t go away. In the same way we need to see a welder actually weld, we need to see a software engineer actually solve a problem.

The field of software engineering is so large today that it feels daunting to know everything. Rather, we can’t know everything. But, we sometimes interview this way.

We sometimes ask front-end engineering candidates to execute long bash commands. We sometimes ask Java engineers to build out an AngularJS application. We sometimes ask QA engineers to construct binary search trees.

The easy answer is to only ask questions that fall within the candidate’s domain of expertise. But, this only solves for job-specific knowledge. This doesn’t solve for communication and/or collaboration skills. We still need to find a way to ask a candidate questions in which we can accurately assess both #1 and #2 from our list above (#3 and #4 are less important, of course).

One Alternative

I changed my interviewing approach this year in order to try to assess both a candidate’s job-specific knowledge as well as her communication and collaboration skills by asking a large question that fit within the domain of the candidate’s expertise and comfort area.

For example, I interviewed a smart 22 year-old computer science major college graduate for a front-end engineering position. He didn’t have much experience but he was passionate and had all the inspiring energy every company needs. The first question I asked was, “what are some of your favorite websites today?” He answered enthusiastically about a website that he spends hours browsing every week. So, we used that website as our foundation. Over the course of the next hour, I asked him to talk me through how he would architect the front-end for this website. As he gave me answers, I asked what he thought the downsides and upsides were. I asked whether he, as a consumer of this website, would like to see anything done differently in terms of performance or usability. It went on and on. I didn’t know anything about this website. This was the first time I saw it. But by starting with something that he was excited about, it was easy to have a technical conversation in which I began to understand what he knew very well and what he was capable of learning to fill in his gaps. Our focus was less about his ability to solve a concrete problem than his ability to think critically by applying his technical knowledge to a product he knew well.

In another case, I started an interview with a senior backend engineering candidate with, “what are some of your favorite technical things right now?” The candidate immediately responded with event-stream processing. We spent the next thirty minutes talking about this topic. I asked questions. She talked about the differences between various options and how they would be implemented. We abstracted the conversation to talk about how this would fit in a larger system and then we talked more about the details of a particular event-stream process itself.

And in a final example, I interviewed a backend engineering candidate in which we talked about how he would architect Netflix’s service layer in preparation of a denial of service attack. Five minutes into the interview, the candidate told me that he didn’t know what Netflix was doing about a particular topic. My response was that it didn’t matter. It was less important to discuss what Netflix actually did than to understand what he would do.

I found this process for interviewing to be more informative than whiteboarding solutions to the “reverse a string” question. I learned a lot about how the candidates communicated their knowledge. And since the topics generally fell within the candidate’s interest areas, I also found the responses to be more inspired and creative.

Keep The Whiteboard

For the majority of candidates, we still need to ask technical questions that can give us insight into the candidate’s capabilities. Whiteboards neither help nor hurt but the questions we ask and the way in which we ask them can change the entire interviewing process.

Interviewing is stressful. It’s very hard to stand in front of a group of strangers and defend one’s abilities. I know some people who don’t leave their current position because they fear interviewing. How we interview can help those people.

And so, I’d challenge you to rethink your interview process so that you are interviewing a candidate in an environment that is less intimidating. Give your candidate a safe domain in which she can answer questions and I think you’ll get better visibility on whether this is the right candidate for you.

And if you have further ideas on how we can all interview better, please let me know.

Stop Whiteboarding was originally published in The Rime of the Digital Mariner on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s Just A Tool

“What’s JSBin.com?” my colleague asked me.

“It’s a website front end engineers use to quickly prototype code. There are a few websites like it.”

“And corporate IT blocked it?”

“I submitted a request to open access to the site but it was denied.”

“Why do you need it?”

“It’s kind of standard process to have tools like this.”

“Can you use something else instead?”

Did I need it?

Could I use something else? I thought about these questions for a while. The problem was that it wasn’t just JS Bin. JS Bin was just the example. It was the same story for a lot of tools I used to do my job.

Fish Out Of Water

I recently took a job with a large retail bank.

Wait, wait! Don’t go!

Having spent years working at tiny and matured start-ups, there are some validating and insightful learnings gained from seeing how an enterprise makes things.

I’m creating a software engineering office with a goal of changing the way the bank (savings and checking accounts) creates customer-facing products. We’re trying to change the retail bank from the inside out. The crucial word in the previous sentence is inside.

We are not creating a start-up from scratch in a far away land. We have to start with the systems and processes that are currently in place. And as I’ve learned, some of those systems and processes are not good.

JSBin.com is a website that lets front end engineers experiment and prototype with JavaScript, CSS, and HTML.

Before I go any further, I should explain what a front end engineer is because I’ve learned it’s important not assume you know. Like many of us in technology, I must empathize more with the idea you might not spend all of your hours working on the internet. You might not know the difference between a front end, back end, or quality engineer other than the unfortunate, funny naming.

A front end engineer makes sure the website you’re browsing right now looks and behaves as you might expect it to look and behave.

The page should have the correct information, layout, and design. It should respond to clicks, taps, and scrolls. It should be quick to load and easy to navigate on any device you use. A front-end engineer accomplishes this by writing code that can be rendered on internet browsers like this one.

JS Bin is a tool the front end engineer can use to develop websites. There are many like it. It allows the user to quickly debug or test ideas. And, it does so in an environment we call a sandbox, a testing environment that allows an engineer to safely test code without impacting users.

Long ago, someone in a far off land, somewhere had decided this site was dangerous and I should not be allowed to use it.

Does Plato Care?

In Plato’s Allegory of the Cave, the Greek philosopher described a situation in which a group of human beings living in an underground cave have no awareness or access to the outside world.

Chained by their legs and heads, they stare at a wall without the ability to see anything else but shadows cast upon it. These shadows were created by people carrying statues and animal figures as they walk in the space between the prisoners and a distant fire.

Plato’s character Socrates asked Glaucon questions about the prisoners’ reaction to this situation. Glaucon is a bit of a yes-man.

[Socrates] And if they were able to converse with one another, would they not suppose that they were naming what was actually before them?

[Glaucon] Very true.

Socrates is saying that the only awareness the prisoner has is of the shadow, nothing else. But what if there was a noise and it looked like two shadows were interacting with one another? Surely then, the prisoners would realize it was not a shadow that made such a noise.

[Socrates] And suppose further that the prison had an echo which came from the other side, would they not be sure to fancy when one of the passers-by spoke that the voice which they heard came from the passing shadow?

[Glaucon] No question, he replied.

So, the peoples’ scope of knowledge was limited to what they saw. There was no possibility of identifying something that may have created the shadows. The truest thing these people knew were the shadows.

But, what happens if the prisoners become unchained? What happens if they see what we see? What does it mean for the people to see the objects that are causing the shadows?

[Socrates] … just as the eye was unable to turn from darkness to light without the whole body, so too the instrument of knowledge can only by the movement of the whole soul be turned from the world of becoming into that of being, and learn by degrees to endure the sight of being, and of the brightest and best of being, or in other words, of the good.

It’s easy for us to know that the shadows are caused by objects because we have access to the complete environment. The prisoners don’t have the same perspective. We can see the people, the statues, and the fire in relationship to each other.

Is it hard to imagine ourselves in this situation? How many times have we made decisions only to have been proven wrong at a later moment of revelation? How many times have we thought the shadows were the only real players in the scene?

Breaking Corporate Chains

Thankfully, our modern HR department has banned chaining prisoners.

Despite the lack of metal restraints, we can sometimes still be imprisoned. We are chained by the processes and systems and beliefs and understandings we have accepted to be as solely true as the shadows on the wall.

Naturally, this begs the question: if we think we might be looking at shadows, how do we remove our restraints so we can see truer knowledge? How do we free ourselves? How do we help free others?

The JS Bin shadow inspired fear, danger, and risk. It made people uneasy and they wanted nothing of it. It needed to be banned. Why? It was classified as a file sharing website.

File sharing websites are banned because the company doesn’t want its employees sharing confidential information, either intentionally or unintentionally. This is a valiant reason. We want nothing more than to protect our customers.

But, JS Bin isn’t a file sharing website. It’s a tool for prototyping code.

This was the moment when I had my learning: I was not doing a good enough job educating people about what software engineers do. If a non-technologist didn’t know what I did, he would put processes and systems in place that would conflict with what I needed.

There was a misunderstanding and confusion around technology and shadows.

The Pace Of Technology Is Leaving Non-Technologists Behind

GitHub hosts 25 million projects today.

Medium had over 1,000 posts a day in 2014. Hacker News had over 600 links with over 100 points in 2013. And if you ask someone randomly what either of those three sites are, what do you imagine they’d say?

In a tech environment, most people know them without question. But outside this bubble, it’s less frequent.

Today, software engineering is a critical part of many industries that did not rely upon it in the past. Technologists work side by side with non-technologists. And as I’ve learned, non-technologists sometimes make decisions based on the shadows they see.

But how could someone make such a decision? How do non-technologists make sure they are not preventing engineers from using tools to do their jobs?

This is where we, as technologists, come in.

We, the people who can see all of the cave, can’t complain. We can’t yell. We can’t be upset.

We have to teach people.

We must explain what we do. We must share what tools we use. We must show people how we make things. We must bridge the gap between the technologist and the non-technologist, the observer and the prisoner.

If we share, there will be an easier conversation around opening up the big corporate firewall.

If we don’t, we’ll all be staring at shadows.

The Shadow Isn’t Real was originally published in The Rime of the Digital Mariner on Medium, where people are continuing the conversation by highlighting and responding to this story.