Click here to close now.


Microservices Expo Authors: Carmen Gonzalez, Liz McMillan, Pat Romanski, Yeshim Deniz, Jason Bloomberg

Related Topics: Microservices Expo, SYS-CON MEDIA

Microservices Expo: Article

i-Technology Viewpoint: When to Leave Your First IT Job

"Don't Work in Cubicles, Ever" – IT Workplace Advice From the Front-Line

It was early May of 2004, and I was almost at the finish line for my degree. Between me and graduation: Just two summer classes. I was in the process of finishing what could only be described as the most intense spring semester of my college career. As the semester's end finally hit, I realized something. I was going to need a job, and I hadn't even started looking.

Then, almost on cue, the phone rang. The president of a small and local software company was looking for computer engineers with .NET experience. They searched my university's resume database for candidates, and I came up. Would I like an interview? Hell yes.

I was to be part of a team of highly skilled, versatile, .NET Ninjas. We were going to produce top-notch software for the nuclear power industry. Combining management's knowledge of the nuclear field and our kung fu grip on .NET , we hoped to dominate our market niche. As developers we would be on the ground floor of a booming company. There was greater room for advancement compared to a traditional office environment. We all hoped to have company cars, top-notch health care, company cell phones, and tons of other wonderful perks; all just slightly out of reach.

It did not go as planned.

One stressful year later, while I was staying late with a few other developers to finish up on some work, I was asked to report to the president's office. My manager was already there, sitting on the same side of the desk as the president. They explained to me, in a level and professional tone, that due to financial factors, I was going to be let go, with only an hour's severance pay. Thanks for all the hard work, and best of luck.

The first layoff is tough. After bending over backward, after being a loyal employee, this is the reward? To summarize how I felt: Disillusioned. Only one thing kept me going -- pure ego. You know when the schoolyard bully says something about your mom in front of everyone? But, ignoring the size difference and the fact that he's already shaving daily at age 14, you step forward and say "Oh yeah?", with a Brock Sampson-like eye twitch the only warning of the impending ownage? That's the kind of ego that kept me determined to give software engineering a second shot.

Over the course of the previous year, my friends quickly learned I liked to talk about work less and less. When I did open up about it, they were astounded by, well, let's say various factors of the work environment. Each and every time it was discussed with my peers in the field, time and time they gave me the same advice: Get out.

I have to say, they were totally right.

All the signs were there, but I blazed on, telling myself that this was just a rough patch for the company, and that we'd pull out of this tailspin in time to land safely at our destination. I was ignoring the pilots screaming "Mayday, Mayday".

Now, while I was blind to obvious signs that it was time to leave, doesn't mean that you have to be. I would like to present the 4 signs that you should leave your workplace (for software engineers):

1. It's the environment, stupid!

In the University of Pittsburgh's Computer Engineering program, there is a mandatory department seminar, where the department informs us about our career options. Oftentimes, alumni come back to speak about the career opportunities in their field. It's all very, very dry, and as a result, nobody listens. They also fail to give one piece of advice that I would at the first seminar of every year, if I was ever asked to give one:

Don't work in cubicles, ever. Working in cubicles is the sure sign that you're not working for a successful company. Imagine the smartest person you know, working in your field. Now imagine how they would react if they were told they're going to work in a box with no door or roof, allowing them no privacy.

They would no doubt leave that organization for one that is less creatively stifling. So unless you are convinced that you're stupid (and, in that case, you're in the wrong field) you shouldn't be accepting cubicles in your work place either. If the company will not or can not spend the money to create offices for its knowledge workers, so they can get into the zone, the odds of it creating a successful software product and capitalizing on it are about the same as you becoming a millionaire by going to Las Vegas, betting fifty on black, and letting it ride all night.

Cubicles do not automatically make an employee stupid; but it is one more barrier for you to climb over before you can create your own space to think. At my last workplace, the noise traveled. Everyone could hear everyone. An intern with nothing to do bullshitting with your boss, a co-worker venting about how he's not paid enough, the busybody secretary ordering people around with no authority. Not one single employee liked the set up, but without management's understanding, naturally nothing was done.

And for those management types who live in the dead end of corporate culture, if you don't believe noise is a big detriment to your productivity, just buy an electric drill or vacuum cleaner. Turn it on and let it run. Put it as close to your ear as humanly possible, and try to get work done.

It sounds like such a small thing to critical about, but like so many things in life, little things turn out to be extremely crucial. Little things snowball into bigger things. If people can't relax in their workplace, dealing with them becomes difficult, which creates friction where none should exist. That friction could destroy the delicate cohesion every team needs to maintain to produce software. So if you find that getting ready for work in the morning is a larger effort then getting ready to go out on a Friday night, maybe you should talk to your boss about making your workplace more accepting, or find a new one.

2. Just How Dumb is Management, Anyway?

Engineering n-tier enterprise level software is like navigating a minefield. There are countless potential disasters just waiting to happen. From creeping requirements to budgetary nightmares to horribly incorrect estimates, oftentimes it is not technical ability that makes or breaks a product; it is how all the other chainsaws are juggled. Your project is as dependent on the know how of your manager as it is your technical ability.

Since the inception of the term, software engineering, people have acknowledged that it is inherently hard to manage software projects. It is exponentially harder to have a superior that actually understands this, and is capable of both properly delegating and managing the complexity. Here are three major mistakes to look for in your manager. Take any of these as a sign that it is time to have that interview suit dry cleaned.

A. Thinks they know too much:

Is your superior an old hand, who's worked his way up from the trenches, but hasn't kept up with the pace of technology? Does he base his assumptions of how you should be doing things based off the way that he did things? So while you try to explain that the create_user_account module should call a stored procedure in the database to minimize the chance of SQL injection, he's showing you how easy it was to create a form in Access97. Questioning the methodology at work will often result with a "this is how we did it in the old days, and I don't see anything wrong with that!" New technology isn't likely to be adopted at its full potential in a workplace with a manager like this. Instead, you will end up grinding the same gears, only faster, louder, and harder.

B. Relies on, but disregards your technical advice:

Oftentimes, a non-technical manager, or an "old hand" who's edge is no longer sharp will be impressed enough to listen to your technical advice. If they were smart, they'd actually take it.

My former company had the unlucky experience of needing to reformat its single production server. While our DBAs tried to figure out what caused the crash, and how to fix it, I began talking to various other developers about what needed to be done if we had to recover from a worst-case scenario, where a reformat/reinstall was necessary.

I studied up on the re-install procedures, so that I could come in over a weekend, fix the sever, and have it ready so that everyone could work on Monday. I told my superior, who promptly disregarded it. That task was going to another employee, one who had no experience in setting the server up properly. If you find yourself in a situation where management is disregarding the sound technical advice they should be basing decisions on, you need to expedite your job search.

C. Schedule Bullies:

This one needs no explanation. If you tell management that it will take 8 days, and they turn around and tell you they think it will take six, you need to leave. Rushed work is almost always subpar. You will not learn sound defensive coding practices. If management does share your view of "I'm writing this, I'm the only one who can tell how long this is going to take." then you have an uphill battle explaining to your boss such difficult terms as quality or pride in your work. I wish you luck on that endeavor. It will be as fun as herding cats.

Remember, not all programmers make good managers, just like not all managers make good programmers. If your boss' skill set brings nothing to the table, don't expect to replace him anytime soon. Instead, get your references ready.

3. Personal Growth

At my last job, I constantly felt dejected. "You're not growing fast enough! You're barely in the middle of the pack." was the kind of feedback I was getting from my supervisor. Much later, I realized they were setting employees up for failure, and then blaming the employee, instead of blaming themselves.

When it comes to growth, you need to consider two things about your company. Are you happy doing what you're happy doing? Do they have you developing in-house tools, when you'd rather be developing next-generation user interfaces? Are you finding yourself spending half your time fixing the network and pulling cable when you'd rather be developing a framework for your fellow developers?

The second thing you need to consider is what kind of options they offer for career advancement. Will the company you're working for pay for graduate schooling in your field? What about management classes? How about industry certifications? If the answer to any of those three is no, the company is trying to trap you, by removing the path most employees use to get better jobs: Expanding on their experience and education. Plenty of companies now offer this benefit to developers, so if yours doesn't, find one that does. You'll thank me when you have that nanotechnology Ph.D.

4. Compensation and Overtime

If you're not happy with the amount of money that you're making, do a reality check. Find out what you're worth. If you are confident your compensation is inadequate, extend your superior the opportunity to rectify this mistake, and then start looking for jobs where you will be valued.

Overtime should also be considered along with compensation. If you're working too many hours at the office, and the company isn't doing whatever it takes to get you back down to a healthy 40 hour work week, then something is wrong. Is it because the network is breaking and none of you know what to do? Hire a network administrator with certifications. Are you talking to vendors and doing the legwork on products you might need later down the pipeline that a temp could do instead? Are you testing software instead of a full time tester?

While the occasional (paid) overtime is nice, long hours put more wear and tear on you, and over time, can cost you the passion you had for developing quality software. No amount of profit sharing, casual dress or office perk can get that back for you.

Final Thoughts

Work is not all bad. A lot of employers say they want their employees to think work is fun. Few employers put their money where their mouth is, and difference is something you not only see - you feel it when you start working for those employers. After reading this, you should have some concrete feeling as to whether you feel your employer measures up, or whether you need to move on. If you start thinking more about your career and less about your particular job, you'll start to pay attention to those warning signs. And for those of you feeling those warning signs:

I'll offer you the same two words of advice that my friends gave me: Get out.

Comments (8) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Anonymous 10/15/05 03:15:45 PM EDT

This article reminds me of the junior pups that I worked with in various companies - they all seem to think they know everything and demand the world, but then when something doesn't go their way, they get all angry and blame management for this.

Hate to tell you this, sport, but as someone who has been around the block a hell of a lot more than you have, you have a lot of growing up to do. This isn't the "dot-com" boom time where you can have no experience in a field and become a Director or VP overnight.

People nowadays want SMEs and people who have a clue - people who can contribute and not bitch about the fact they have a cubicle versus a hard walled office.

I would feel remotely sympathetic to you if 1) you were not given the proper equipment to do your job (this has happened to me more times than I care to count 2) I am surrounded by coworkers who sit on their collective asses and complain that you aren't working hard but they are there doing even LESS and demanding MORE (been there too) 3) you have a boss who refuses to communicate with you, even when you just join the company and expect you to figure out by osmosis what the goals of the company are and you are to chart your own course (this has happened to me as well).

So... to make a long story short, you are an ungrateful little punk who might be better off working in an electronics store or a fast food restaurant. If you can't handle how companies think or operate, then I suggest you see what's wrong with YOU before you look at the company and their flaws.

I know for one thing, I wouldn't hire you to work with me - you seem to be very high maintenance and I can't deal with that -- we want results and we want team players but ones who actually can work on their own - it seems to me you can't even do that right...

Good luck to you... you will REALLY need it.

damienm 10/13/05 09:01:47 AM EDT

Chris, the innocence of inexperience is all I can say to describe your view! You have a long way to go before you can give solid advice to people on how they manage their career. Admittedly there are some factors in your argument that hold water. The logic you use, however, indicates your lack of objectiveness and experience. While you might very well strike it lucky irrespective of your attitude, it is an attitude that would make you an unlikely candidate for hiring for the reason that it indicates that you are nowhere near as effective in a work situation as you might think you are. Don't let your bitterness about one situation mold your view from this point forward. With any luck you'll look back on this article in 10 years time and laugh at your innocence, perhaps even blush!

Keep an open mind, man... good luck in your future career.

mohamed yusu faizal 10/12/05 04:26:27 AM EDT

Christopher excellence has been proved keep it up

Free Thy emoTiOns 10/09/05 10:47:40 PM EDT

Trackback Added: Why should you leave your tech job.; Being in the tech line, there are stuff I read in there that make sense. But then again, I think the place I work in does not really has some of the restrictions, cause I work alone.
Schedule bullies do not only apply to the IT industry, many industr...

ohbayy 10/07/05 02:39:48 PM EDT

Excellent article Christopher Wilson. You got the key issues hammered-out, spot-on. Way to go. I really hope a lot of stay-put, miserable programmers read this.

Wolfgang 10/07/05 09:00:52 AM EDT

Ahh, the idealism of youth. I work for one of the largest and most profitable insurance companies in the world and guess what? Surprise, Surprise: cubicles. I've also worked for engineering companies that build hardware and have done embedded code - also successful companies, also cubicles. This sounds like the same type "woulda, shoulda, coulda" whining that I hear from my interns. And no, I'm not a manger - I'm a senior technical architect (an "old hand" if you like, who has kept current on technology). The answer is fairly simple - if you work for "start-up" companies you have great opportunites if you are in on the ground floor (i.e. Microsoft millionaires)but also have to understand the balancing side of the equation -with this type of opportunity comes great risk. For every Microsoft or Oracle out there, there are 5,000 starups that fail or achieve mediocre success at best. So if you are going to work in high risk/high reward environments, accept the fact that the probability of the type of experience you had repeating is high. Or take a different road. And while you are whining about your manager and how unfairly you were treated by the company, think about how much those same owners invested and lost. I can assure you they did not fail just to persecute you. If you want security, join a big corporation (even that is no garauntee today with all the outsourcing)- but then you'll have to deal with the rules an regs - dress codes, cubes, bosses who want you to report your status at least 3 different ways. Your only option for the complete creative freedom you want is to come up with, develop and sell your own product. Of course, if you are even slightly successfull, you will become the "man" and do to a new crop of software engineers all the horrible things that you endured. This is called "business". Deal with it.

Tiger One 10/06/05 02:54:32 AM EDT


Great write up.

One question, all these are points that can only be answered once you have already started working in a company. How can one judge a company from what is available when you walk in for the interview.


Yakov Fain 10/05/05 04:20:53 PM EDT


Just stop whining, will you! This entire article is about yourself and how bad guys underestimate you.If you are following your own recommendations, you should not be working for the same comany for more than a couple of months. Whenever something goes wrong your response is always the same: update your resume and run. Just relax a bit... Most of the software engineers work in cubicles, and some of them are making tons of money. And if you do not like the noise around you, put on the headphones and listed to some elevator music.
Yes, not all managers are the smartest people in the world, but they need to worry about more things than just bringing a server up. Try to ajust to the environment you're in now, or you'll run out of emploeyrs to go to. It's a small world, really.
Meanwhile, our friends from Asia will be more than happy to move into your noisy cubicle.
Put yourself together and see what has to be done to have a better review then "in the middle of the pack".
As the President Bush put it, "You can run, but you can't hide!".

Sorry for the angry tone :)

@MicroservicesExpo Stories
Containers have changed the mind of IT in DevOps. They enable developers to work with dev, test, stage and production environments identically. Containers provide the right abstraction for microservices and many cloud platforms have integrated them into deployment pipelines. DevOps and Containers together help companies to achieve their business goals faster and more effectively.
The web app is agile. The REST API is agile. The testing and planning are agile. But alas, data infrastructures certainly are not. Once an application matures, changing the shape or indexing scheme of data often forces at best a top down planning exercise and at worst includes schema changes that force downtime. The time has come for a new approach that fundamentally advances the agility of distributed data infrastructures. Come learn about a new solution to the problems faced by software organ...
Achim Weiss is Chief Executive Officer and co-founder of ProfitBricks. In 1995, he broke off his studies to co-found the web hosting company "Schlund+Partner." The company "Schlund+Partner" later became the 1&1 web hosting product line. From 1995 to 2008, he was the technical director for several important projects: the largest web hosting platform in the world, the second largest DSL platform, a video on-demand delivery network, the largest eMail backend in Europe, and a universal billing syste...
Saviynt Inc. has announced the availability of the next release of Saviynt for AWS. The comprehensive security and compliance solution provides a Command-and-Control center to gain visibility into risks in AWS, enforce real-time protection of critical workloads as well as data and automate access life-cycle governance. The solution enables AWS customers to meet their compliance mandates such as ITAR, SOX, PCI, etc. by including an extensive risk and controls library to detect known threats and b...
Docker is hot. However, as Docker container use spreads into more mature production pipelines, there can be issues about control of Docker images to ensure they are production-ready. Is a promotion-based model appropriate to control and track the flow of Docker images from development to production? In his session at DevOps Summit, Fred Simon, Co-founder and Chief Architect of JFrog, will demonstrate how to implement a promotion model for Docker images using a binary repository, and then show h...
DevOps has often been described in terms of CAMS: Culture, Automation, Measuring, Sharing. While we’ve seen a lot of focus on the “A” and even on the “M”, there are very few examples of why the “C" is equally important in the DevOps equation. In her session at @DevOps Summit, Lori MacVittie, of F5 Networks, will explore HTTP/1 and HTTP/2 along with Microservices to illustrate why a collaborative culture between Dev, Ops, and the Network is critical to ensuring success.
Overgrown applications have given way to modular applications, driven by the need to break larger problems into smaller problems. Similarly large monolithic development processes have been forced to be broken into smaller agile development cycles. Looking at trends in software development, microservices architectures meet the same demands. Additional benefits of microservices architectures are compartmentalization and a limited impact of service failure versus a complete software malfunction....
Despite all the talk about public cloud services and DevOps, you would think the move to cloud for enterprises is clear and simple. But in a survey of almost 1,600 IT decision makers across the USA and Europe, the state of the cloud in enterprise today is still fraught with considerable frustration. The business case for apps in the real world cloud is hybrid, bimodal, multi-platform, and difficult. Download this report commissioned by NTT Communications to see the insightful findings – registra...
Manufacturing has widely adopted standardized and automated processes to create designs, build them, and maintain them through their life cycle. However, many modern manufacturing systems go beyond mechanized workflows to introduce empowered workers, flexible collaboration, and rapid iteration. Such behaviors also characterize open source software development and are at the heart of DevOps culture, processes, and tooling.
Containers are revolutionizing the way we deploy and maintain our infrastructures, but monitoring and troubleshooting in a containerized environment can still be painful and impractical. Understanding even basic resource usage is difficult - let alone tracking network connections or malicious activity. In his session at DevOps Summit, Gianluca Borello, Sr. Software Engineer at Sysdig, will cover the current state of the art for container monitoring and visibility, including pros / cons and li...
DevOps Summit at Cloud Expo 2014 Silicon Valley was a terrific event for us. The Qubell booth was crowded on all three days. We ran demos every 30 minutes with folks lining up to get a seat and usually standing around. It was great to meet and talk to over 500 people! My keynote was well received and so was Stan's joint presentation with RingCentral on Devops for BigData. I also participated in two Power Panels – ‘Women in Technology’ and ‘Why DevOps Is Even More Important than You Think,’ both ...
In a report titled “Forecast Analysis: Enterprise Application Software, Worldwide, 2Q15 Update,” Gartner analysts highlighted the increasing trend of application modernization among enterprises. According to a recent survey, 45% of respondents stated that modernization of installed on-premises core enterprise applications is one of the top five priorities. Gartner also predicted that by 2020, 75% of
As the world moves towards more DevOps and microservices, application deployment to the cloud ought to become a lot simpler. The microservices architecture, which is the basis of many new age distributed systems such as OpenStack, NetFlix and so on, is at the heart of Cloud Foundry - a complete developer-oriented Platform as a Service (PaaS) that is IaaS agnostic and supports vCloud, OpenStack and AWS. In his session at 17th Cloud Expo, Raghavan "Rags" Srinivas, an Architect/Developer Evangeli...
Our guest on the podcast this week is Jason Bloomberg, President at Intellyx. When we build services we want them to be lightweight, stateless and scalable while doing one thing really well. In today's cloud world, we're revisiting what to takes to make a good service in the first place. Listen in to learn why following "the book" doesn't necessarily mean that you're solving key business problems.
For it to be SOA – let alone SOA done right – we need to pin down just what "SOA done wrong" might be. First-generation SOA with Web Services and ESBs, perhaps? But then there's second-generation, REST-based SOA. More lightweight and cloud-friendly, but many REST-based SOA practices predate the microservices wave. Today, microservices and containers go hand in hand – only the details of "container-oriented architecture" are largely on the drawing board – and are not likely to look much like S...
In their session at DevOps Summit, Asaf Yigal, co-founder and the VP of Product at, and Tomer Levy, co-founder and CEO of, will explore the entire process that they have undergone – through research, benchmarking, implementation, optimization, and customer success – in developing a processing engine that can handle petabytes of data. They will also discuss the requirements of such an engine in terms of scalability, resilience, security, and availability along with how the archi...
Any Ops team trying to support a company in today’s cloud-connected world knows that a new way of thinking is required – one just as dramatic than the shift from Ops to DevOps. The diversity of modern operations requires teams to focus their impact on breadth vs. depth. In his session at DevOps Summit, Adam Serediuk, Director of Operations at xMatters, Inc., will discuss the strategic requirements of evolving from Ops to DevOps, and why modern Operations has begun leveraging the “NoOps” approa...
The last decade was about virtual machines, but the next one is about containers. Containers enable a service to run on any host at any time. Traditional tools are starting to show cracks because they were not designed for this level of application portability. Now is the time to look at new ways to deploy and manage applications at scale. In his session at @DevOpsSummit, Brian “Redbeard” Harrington, a principal architect at CoreOS, will examine how CoreOS helps teams run in production. Attende...
With containerization using Docker, the orchestration of containers using Kubernetes, the self-service model for provisioning your projects and applications and the workflows we built in OpenShift is the best in class Platform as a Service that enables introducing DevOps into your organization with ease. In his session at DevOps Summit, Veer Muchandi, PaaS evangelist with RedHat, will provide a deep dive overview of OpenShift v3 and demonstrate how it helps with DevOps.
All we need to do is have our teams self-organize, and behold! Emergent design and/or architecture springs up out of the nothingness! If only it were that easy, right? I follow in the footsteps of so many people who have long wondered at the meanings of such simple words, as though they were dogma from on high. Emerge? Self-organizing? Profound, to be sure. But what do we really make of this sentence?