As I have gotten older, my social life has waned, but every now and then, I venture out, just like in the good old days….
Recently, I did just that. Met some friends, had some drinks, chatted. I hadn’t seen them for a while and the conversation turned to my work, my job. They asked if I was still enjoying it, if I had made the right decision to change careers etc.
Then came the million dollar question: WHAT DO YOU ACTUALLY DO?
Cue the charades answer:
Past that, I was pretty much stumped - it is really difficult to explain what you do as a “developer” or “coder” when someone has no idea what you are talking about.
So, I am going to try to answer it now…..
These are the things (I can think of) that I do on a daily basis:
- type/write “code”
- think
- stand up (you just stand up?)
- meetings - planning, estimations, spikes
- swim
- eat - lunch, fruit
- drink - coffee, hot chocolate, water, squash
- go home, work (sometimes)
Most of these are self-explanatory. The second half of the list is the easy stuff. In fact, it might be easier to work up from the middle…
Meetings, planning, estimations, spikes
- Meetings: fairly obvious, even to the un-scrummed
- Planning, easy.
- Estimations? Well… yeah, fairly easy. We estimate how much effort a job/task/story/thing will need to be completed. Sometimes this considers time, but mostly how hard it will be (and this is the important bit:) compared to other pieces of work we have completed. This enables us to get a slightly more accurate idea of how difficult a job might be. We then do more planning on these smaller chunks of work. If we know something more simple took less effort/time, we know this thing will take longer, more people, more planning, more investigation beforehand etc.
- Spikes: these are time-limited “investigations” into the bigger chunks of work. It might involve individually looking into technologies that haven’t been used in our project before. It might be a few of us whiteboarding options, padding out ideas, thinking about where this thing might go in the future and how we can plan for that. These then help us estimate the bigger chunks of work.
Stand up
Another bit of an odd one if you don’t agile/scrum/scrumbut, but effectively, everyone in a team stands up together and generally talks briefly about three things:
- What you did yesterday
- What you plan to do today
- What is blocking you (what is stopping you from getting what you plan/planned to do done)
It takes about 15 - 20 minutes, but ideally shouldn’t be too long. It helps get problems out in the open - if I am “blocked” by something, somebody else might have encountered that problem already. Talking about it might get different opinions or approaches which all help to get the job done.
Think
This one is obvious, but maybe not so much to some people. I have lots of things around my desk which you would NEVER see in any other job I have done:
- Rubik’s cubes
- A guitar
- Fidget spinner
- Colouring books, pens/pencils
- Books
It is good to think. All of the things above help clear my head. Sometimes, it is good to take a step back, slow down, think about what you are doing, then go back to it fresh. It doesn’t have to be hours, but sometimes any brain-rest time will help.
It would also be very strange (and probably frowned upon) in most of the other jobs I have done to spend time just staring into space, thinking for any amount of time.
But in this job, it helps.
Type / write code
This is the really difficult one. I guess it covers most of my time. But is the hardest to explain, as much as the Jim Carrey gif does try.
How do you explain something very technical to somebody not necessarily non-technical, but with no idea of how to write any sort of code?
I remember this from when I was a kid:
10 Print “Hello”
20 Goto 10
Enter
I’ve always enjoyed messing around with computers, always dabbled on and off with some sort of code (I also remember trying to figure out linux on a ps2!). So it kind of makes sense to me. But if this doesn’t sound like you, it probably will make sense if I explain what I do.
I mostly focus on backend development in my day to day work. This means that instead of programming the things you see in your browser, I write the bits that you don’t see. For example, if you log into your online banking, it shows you all of your accounts, savings, credit cards etc.
These will all (most likely) be stored in a database. The developer will then build a bridge between the browser and the database. This will involve retrieving the appropriate data from the database (somehow) and sending it back to the browser (by witchcraft, normally).
You want to make a payment/transfer somewhere? You put the payment information into the online banking in the browser, the backend developer takes your request for a transfer, does some stuff, then the money arrives at the destination.
This is where the planning and spikes etc. come into play - I could just delete the amount from the one account record and add it to the other, but that would just be silly. What if you don’t have enough money to transfer in the first place? What if the account/destination you want to send money to doesn’t exist? What if there are tax implications of where you are transferring to? What if, what if, what if….
TL:DR
This is what a developer does - it is working with the what ifs. The whys. The whens and the hows: dealing with those, figuring out how to handle them, then converting those thoughts, ideas and plans into a language that computers understand using an already constructed language with different operators and built-in functions to make that as simple and as clear as possible.
Any clearer? Maybe, maybe not. It’s got to make a bit more sense than the typing mime, right?
Latest comments (0)