My first job out of college I was given a development task by my manager. I went through the requirements and noticed that it wouldn’t be possible to implement them as written. So I gathered up my materials and walked into my manager’s office. I explained to her what the issue was and told her I couldn’t complete the assignment.

She looked at me for a moment, as if expecting something more, and then said, “So how do we resolve this?” I was taken aback. I told her again that the requirements couldn’t be implemented - as if she hadn’t heard me the first time.

She looked at me for another moment and said to me, “Don’t ever come into my office again with a problem until you’ve spent time thinking of solutions”. Her message was crystal clear. It wasn’t her job to solve my technical problems. That’s what she was paying me for.

As architects and developers it’s our job to solve those technical problems and implement realistic solutions. It’s not a viable option to reach a road-block and throw up our hands. We can’t rely on anyone else to bail us out when the going gets tough.

I’ve taken that to heart for the entirety of my career. That meeting with my long-ago manager was the last time I was at a loss for alternative solutions. And it’s a lesson I’ve attempted to pass on to others.

I’ve noticed again and again that’s its a common problem. Especially among developers who think of themselves as cogs in the machine. You’re not a cog. Your job is a difficult one but you have the capacity to solve your own problems and find your own solutions.

So the next time you realize that you’ve reached a difficult stage and that you cannot solve it on your own, don’t setup a meeting or send out an email until you’ve worked out some alternatives on your own. You may not have found the final solution but you’ll make it clear that you didn’t just give up. Because that approach, is unacceptable.

Find your own solutions

My first job out of college I was given a development task by my manager. I went through the requirements and noticed that it wouldn’t be possible to implement them as written. So I gathered up my materials and walked into my manager’s office. I explained to her what the issue was and told her I couldn’t complete the assignment.

She looked at me for a moment, as if expecting something more, and then said, “So how do we resolve this?” I was taken aback. I told her again that the requirements couldn’t be implemented - as if she hadn’t heard me the first time.

She looked at me for another moment and said to me, “Don’t ever come into my office again with a problem until you’ve spent time thinking of solutions”. Her message was crystal clear. It wasn’t her job to solve my technical problems. That’s what she was paying me for.

As architects and developers it’s our job to solve those technical problems and implement realistic solutions. It’s not a viable option to reach a road-block and throw up our hands. We can’t rely on anyone else to bail us out when the going gets tough.

I’ve taken that to heart for the entirety of my career. That meeting with my long-ago manager was the last time I was at a loss for alternative solutions. And it’s a lesson I’ve attempted to pass on to others.

I’ve noticed again and again that’s its a common problem. Especially among developers who think of themselves as cogs in the machine. You’re not a cog. Your job is a difficult one but you have the capacity to solve your own problems and find your own solutions.

So the next time you realize that you’ve reached a difficult stage and that you cannot solve it on your own, don’t setup a meeting or send out an email until you’ve worked out some alternatives on your own. You may not have found the final solution but you’ll make it clear that you didn’t just give up. Because that approach, is unacceptable.