Welcome!

Microservices Expo Authors: Stackify Blog, Aruna Ravichandran, Dalibor Siroky, Kevin Jackson, PagerDuty Blog

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

Hi,

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.

Cheers,
Tiger

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

Chris,

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
How is DevOps going within your organization? If you need some help measuring just how well it is going, we have prepared a list of some key DevOps metrics to track. These metrics can help you understand how your team is doing over time. The word DevOps means different things to different people. Some say it a culture and every vendor in the industry claims that their tools help with DevOps. Depending on how you define DevOps, some of these metrics may matter more or less to you and your team.
For many of us laboring in the fields of digital transformation, 2017 was a year of high-intensity work and high-reward achievement. So we’re looking forward to a little breather over the end-of-year holiday season. But we’re going to have to get right back on the Continuous Delivery bullet train in 2018. Markets move too fast and customer expectations elevate too precipitously for businesses to rest on their laurels. Here’s a DevOps “to-do list” for 2018 that should be priorities for anyone w...
If testing environments are constantly unavailable and affected by outages, release timelines will be affected. You can use three metrics to measure stability events for specific environments and plan around events that will affect your critical path to release.
In a recent post, titled “10 Surprising Facts About Cloud Computing and What It Really Is”, Zac Johnson highlighted some interesting facts about cloud computing in the SMB marketplace: Cloud Computing is up to 40 times more cost-effective for an SMB, compared to running its own IT system. 94% of SMBs have experienced security benefits in the cloud that they didn’t have with their on-premises service
DevOps failure is a touchy subject with some, because DevOps is typically perceived as a way to avoid failure. As a result, when you fail in a DevOps practice, the situation can seem almost hopeless. However, just as a fail-fast business approach, or the “fail and adjust sooner” methodology of Agile often proves, DevOps failures are actually a step in the right direction. They’re the first step toward learning from failures and turning your DevOps practice into one that will lead you toward even...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
While walking around the office I happened upon a relatively new employee dragging emails from his inbox into folders. I asked why and was told, “I’m just answering emails and getting stuff off my desk.” An empty inbox may be emotionally satisfying to look at, but in practice, you should never do it. Here’s why. I recently wrote a piece arguing that from a mathematical perspective, Messy Desks Are Perfectly Optimized. While it validated the genius of my friends with messy desks, it also gener...
The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
The next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especially great option for projects that require multiple and frequent contributions to be integrated. But… securing CICD best practices is an emerging, essential, yet little understood practice for DevOps teams and their Cloud Service Providers. The only way to get CICD to work in a highly secure environment takes collaboration, patience and persistence. Building CICD in the cloud requires rigorous ar...
The enterprise data storage marketplace is poised to become a battlefield. No longer the quiet backwater of cloud computing services, the focus of this global transition is now going from compute to storage. An overview of recent storage market history is needed to understand why this transition is important. Before 2007 and the birth of the cloud computing market we are witnessing today, the on-premise model hosted in large local data centers dominated enterprise storage. Key marketplace play...
The cloud revolution in enterprises has very clearly crossed the phase of proof-of-concepts into a truly mainstream adoption. One of most popular enterprise-wide initiatives currently going on are “cloud migration” programs of some kind or another. Finding business value for these programs is not hard to fathom – they include hyperelasticity in infrastructure consumption, subscription based models, and agility derived from rapid speed of deployment of applications. These factors will continue to...
Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task ...
Following a tradition dating back to 2002 at ZapThink and continuing at Intellyx since 2014, it’s time for Intellyx’s annual predictions for the coming year. If you’re a long-time fan, you know we have a twist to the typical annual prediction post: we actually critique our predictions from the previous year. To make things even more interesting, Charlie and I switch off, judging the other’s predictions. And now that he’s been with Intellyx for more than a year, this Cortex represents my first ...
"Grape Up leverages Cloud Native technologies and helps companies build software using microservices, and work the DevOps agile way. We've been doing digital innovation for the last 12 years," explained Daniel Heckman, of Grape Up in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
The Toyota Production System, a world-renowned production system is based on the "complete elimination of all waste". The "Toyota Way", grounded on continuous improvement dates to the 1860s. The methodology is widely proven to be successful yet there are still industries within and tangential to manufacturing struggling to adopt its core principles: Jidoka: a process should stop when an issue is identified prevents releasing defective products
We seem to run this cycle with every new technology that comes along. A good idea with practical applications is born, then both marketers and over-excited users start to declare it is the solution for all or our problems. Compliments of Gartner, we know it generally as “The Hype Cycle”, but each iteration is a little different. 2018’s flavor will be serverless computing, and by 2018, I mean starting now, but going most of next year, you’ll be sick of it. We are already seeing people write such...
Defining the term ‘monitoring’ is a difficult task considering the performance space has evolved significantly over the years. Lately, there has been a shift in the monitoring world, sparking a healthy debate regarding the definition and purpose of monitoring, through which a new term has emerged: observability. Some of that debate can be found in blogs by Charity Majors and Cindy Sridharan.
It’s “time to move on from DevOps and continuous delivery.” This was the provocative title of a recent article in ZDNet, in which Kelsey Hightower, staff developer advocate at Google Cloud Platform, suggested that “software shops should have put these concepts into action years ago.” Reading articles like this or listening to talks at most DevOps conferences might make you think that we’re entering a post-DevOps world. But vast numbers of organizations still struggle to start and drive transfo...
Let's do a visualization exercise. Imagine it's December 31, 2018, and you're ringing in the New Year with your friends and family. You think back on everything that you accomplished in the last year: your company's revenue is through the roof thanks to the success of your product, and you were promoted to Lead Developer. 2019 is poised to be an even bigger year for your company because you have the tools and insight to scale as quickly as demand requires. You're a happy human, and it's not just...
"Opsani helps the enterprise adopt containers, help them move their infrastructure into this modern world of DevOps, accelerate the delivery of new features into production, and really get them going on the container path," explained Ross Schibler, CEO of Opsani, and Peter Nickolov, CTO of Opsani, in this SYS-CON.tv interview at DevOps Summit at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.