DEV Community: jennymegan

Is there ever a case for the Knowledge Silo?

jennymegan — Thu, 22 Apr 2021 16:06:25 +0000

I fell down a rabbit hole into a fascinating debate recently.
Techies from across the globe were arguing over the validity of knowledge silo-ing. I'm a n00b in this world and I have been taught - both from a technical and a business point of view - that this is a thing of the past. The theory goes that in industries like manufacturing, the senior staff are those with the most experience. You make furniture for thirty years - you get great at making furniture. You have experience. You teach others, but you are valued very highly not jus tfor your teaching, but for your learned instinct. The furniture making process, therefore the industry, has not changed greatly in decades and your knowledge is relevant and valuable.

In tech, however, we are supposed to be more like those in the field of medicine. Advances in medicine are celebrated and as soon as it is safe to do so, integrated into the field. New skills are learned by young doctors and people would value someone with fewer years' medical experience if they had "better", more up to date procedures under their belt. Obviously I am not suggesting everyone wants to be sliced and diced by a kid out of med school, but Greys Anatomy has taught us we don't want the cardio guy with fifty years experience and a crank to hold open our chest if we can have Cristina Yang with ten years and a laproscopic procedure. The metaphor is that modernity is valued.

Programming, it holds, should follow a similar pattern. There are technologies widely available now that ten years ago were pipe dreams. They're smart, secure, useful, time-saving. And young devs cut their teeth on them.

When these baby devs get dropped into a large company with senior staff who have become senior through years of service - and yes, experience - what should happen?

As I said, I've been taught that the system doesn't work like it used to. That knowledge is shared and the top-down heirarchy in tech companies died in the early 2000s. To an extent, I have seen this in my workplace. I have also seen the most flagrant gatekeeping and insecurity in more senior staff. I was hoping this was anomalous but let me pass over some quotes from the thread I found:

Poster 1 : "If you're the only person who knows something, you become a liability".

Poster 2: "Sorry, this is just wrong. You are a liability if someone thinks about you that way. Fortunately, not that many people are like that. In Contrary, if you are the only one to know something then you are regarded very highly and almost untouchable."

Eye roll.

"Sharing knowledge in the business world, never. That's a great way to lose a job."

There are many more. Enough for this to be clearly still a very prevalent paradigm. I have found that for me the old "see one, do one, teach one" has worked very nicely, and I am never happier than helping someone else figure out how to solve a problem that I too struggled with. But I am wondering how prepared I need to be, in this big bad world, to fight to stay that way!

This is the link, if you want to grab a coffee and exercise your eyebrows (mine must have got stuck somewhere near my hairline for fifteen solid minutes) https://news.ycombinator.com/item?id=26721951

REST APIs - Explained like you're 5

jennymegan — Tue, 16 Feb 2021 15:19:16 +0000

I'm a big advocate of the simple explanation. Even more so since I started a Master's degree which advertised itself as a "conversion" to Software Engineering - I am at about the right level, but use what I learned in my (comprehensive, four month) bootcamp every damn day. Some of the others who joined with me are genuine code virgins and it just feels like no-one is making any effort to explain the basics to them. In the spirit of helping - here's my explanation of REST APIs.

Firstly- APIs. "Application Programming Interfaces". Kind of a complicated concept but one that's often demonstrated with ye olde restaurant metaphor - the front end (pretty website) is the customer eating the food, the back end (database and "brain") is the kitchen, and the waiter is the API.

I take issue with this. IMO, and I might be wrong (I sometimes am, apparently):

You come into the restaurant and make an order. //You go to a website and enter a query
The waiter writes down the order. //The data is captured inside a specific format (ie. Json)
The order is taken to the kitchen THROUGH THE KITCHEN DOOR. //The json data is recieved by the back end through the API

In my mind, the API is more like a door than a waiter. Your data is packaged up and sent to a specific location, where it is recieved and routed to the correct place.

APIs then are just code constructs, live, and on the lookout for data. They are on the lookout for data being sent to them. They can have several routes or addresses to which to send the data, and each route has a different set of things to do to that data.

Perhaps your route is "updateOrder" - in which case when the API gets the data addressed that "endpoint" (yes, another new word which sounds scary, but as you can see, it ain't) it will probably have some logic in there to update an order somewhere, based on some info in that data.

Perhaps your route is "allCatPics" and that endpoint triggers the return to you of some more data, including the URLs of many, many cat pictures. This is more common than you might think.

So, what is a REST API? Is it sleepy? Having a massage? REST stands for Representational State Transfer. God knows. You can ignore that. What it means is that your API and its named endpoints follow a set naming convention.

Its beauty is its simplicity - it is easy to follow, easy to guess, and uniform.
Its downside is also its simplicity - we'll touch on that in a moment.

Stepping back - that waiter has a few options when he goes through the kitchen door. He can wave the order and shout "NEW ORDER, CHEF!", or he can shout "TABLE 5 HATE IT AND SENT IT BACK", or he can shout "READY FOR DESSERT ON TABLE 3".

Likewise, our communication via API can take a few approaches. Chances are you've heard of "POSTing" data. You can also "GET" data (essentially the same, except as the name suggests, you are only making a request to receive data back; a la Cat Pic). There are other options like "PUT" and "DELETE". They are just POST in pretty, semantic, dresses. These are called "HTTP verbs".

This is how REST gets to be so simple. Aside from the endpoint names, you need to use the appropriate HTTP verb.

POST => create a new thing DELETE => delete a thing PUT => update a thing GET => get something

So, that's the first part of the rule. The second part is the naming of the endpoints:

POST www.myUrl.com/thing

ie. a post request to /order sends a new bit of data with it. A new order. This needs to be singular. /cat, /person etc.

DELETE www.myUrl.com/thing/id

Singular word here /thing, and then you get to specify what it is you want to delete- usually done with an id, hence the /id.
beware - some APIs will delete all the data if you forget to give them a set ID here.

PUT www.myUrl.com/thing/id

Same pattern here, but remember above - "put" requests are used to update an existing piece of data. So you can attach some data to this like you did with the POST. Nb. As we discussed, this is actually still a POST request, just in fancy dress. There is nothing technically stopping a PUT request providing the initial piece of data; but in REST rules it is only for updating the data.
Like DELETE, if you forget the ID here, some APIs will update everything to say whatever it is you're sending over here... :D

GET www.myUrl.com/thing

a singular again; ie the same route word as the ones above. You don't send over any new data, just a request for data. The get route here returns ALL the /things - even though it's singular. I don't make the rules.

GET www.myUrl.com/thing/id

here you get an EXTRA thing you can use to just retrieve a certain "thing". The get route within the API code will have some logic in it to check whether you've included an ID, and if you have to just return you that one. Otherwise you get them all.

And a little extra - you can filter using query parameters too. (The query being the bit after the "?").
ie.

GET www.myUrl.com/thing?minAge=18

here is an example of getting all the things that are over 18. You can again implement some logic in the back end to get that query out of the URL, and use it to filter things out of the database to return them. You can use this on PUT, and DELETE too. you wouldn't want to use it on POST in a rest API because you're solely adding new stuff via that command; you can't filter what doesn't exist yet.

So collated with the 4 verbs, you have three possible url structures:

/thing
/thing/{id} (nb it's only in curlies so you know it doesn't have to be an id)
/thing?thing=yes

And that's why REST is so simple. Four verbs, three url endings. The rest of the work is just putting the right combi together for what you want to achieve.

HOWEVER. This can be super restrictive. What if you wanted to get some data for the Things and also the Thangs? You have to do two requests out, one to /thing and one to /thang, and then join that data together at the front end.
Or if you just want to get the Name of all the Things, but the Things are stored with their Fave Color, Haircut Type and Mum's Name too? You have to do a GET request to /thing in order to get the data about all of the things, and then your only option is to filter through that data to just pick out the Thing Name, and ignore the rest. Straightforward, but a waste of resources getting all the info when you only wanted a little bit of it.

Maybe your app just needs to break the REST rules in a couple of places. I wouldn't blame you. In fact, I would say "do not worry, I still have a fancy name you can call your API". It is no longer strictly a REST API, but it is "RESTful". I mean, I would have called it RESTish, but again, I don't make the rules.

I hope this helps understand what people mean when they talk about REST APIs - any if anything is unclear or incorrect, let me know! Every day is a learning day :D

SOLID for newbies

jennymegan — Wed, 18 Nov 2020 13:52:09 +0000

Reading about the "SOLID" principles, or "making code more SOLID" can put the wind up you if you don't know what it means. I mean, we all know coding loves an an acronym, and I for one can find them intimidating. But it's like someone very important once said - Everything is impossible until you know how to do it. Then everything is trivial. (Sorry, important famous person, for butchering your words).

Case in point - DRY. You might, as a beginner learning to code for the first time, see articles or people talking about "Making your code more DRY... how to write DRY code" etc. You might think this is some special trick or complicated new formula you are going to have to knuckle down and learn.

Fear not, intrepid explorer of new things. It stands for "Don't Repeat Yourself". I mean, come on.

Having said that, it's the simple rules like this that really do make a difference in code. The "best" code is short and clean and doesn't repeat itself unnecessarily, and that is harder to achieve than it sounds.

SOLID is a set of principles which are often considered best practice when writing OO (there I go again - Object Oriented) code.

Let's run through them and try and take the mystery out of them.

S - is for Single Responsibility.
Every class you write should have a single responsibility. Not necessarily a single "job", but a set of properties and methods that relate to a single aim. Which is to say, if you have a nice juicy class that you feel smug about because it's holding all your code and isn't it tidy - that's not good. Split it up. Make more classes - you never know how this code might need to change in the future and someone will thank you later.

O - is for Open/Closed. The long phrase is "Classes should be open to extension, and closed to modification". This is, in a way, an extension of the point made above. You should not start adding stuff into an existing class when you add functionality to an application. Extend the class, and work in there. You won't lose anything, and you shouldn't break anything either, in theory!

L - This is a silly one so hang in there. L stands for Liskov Substitution Principle (I know). You can google it if you want. What it means, roughly speaking, is that any child class should be substitutable for its parent. Is that still Greek? Any child class should be able to be used in the same way its parent can be, even if the outcome is different.

I - is for Interface Segregation. I know it sounds scary but it's really not. This means that no class should implement an interface it doesn't need the entirety of. See letter S above. Your interfaces shouldn't do two things anyway, so if you're an obedient practictioner this one won't be a problem for ya.

D - is for Dependency Inversion. Don't lose it now gang, this is the last one. Again, this is way simpler than it sounds. Don't ask me how the dude who invented this came up with that catchy D, but he did. This means, in short, Type Hint to abstracts or interfaces, not to classes. Type hint to abstractions, not "concretions".

I have been a little nervous to post on here about things that aren't subjective; I felt like I wasn't qualified to do so. But on the other hand, I haunted this board as a complete beginner and I would have appreciated - and did appreciate! People walking through the basics. I hope this helps you go forth and sprinkle your tweets with acronyms to sounds super intellectual.

The Perils of PHP

jennymegan — Sun, 08 Nov 2020 19:33:03 +0000

I had an initial assessment with a large company recently. A global financial corporation who advertised their in house "coding academy" or similar. The role was for very junior level devs as it included a few years' of serious training within the company itself.
The wording of the job advert was - and I explicitly checked this - "you should have a base knowledge of coding in any language".

They send you a standard Hackerrank test; it comes with a generic Hackerrank sample test. I did the sample test - it offered the full gamut of languages supported by hr. [I don't know if that's standard abbreviation for Hackerrank but it'll save me typing that out a million times here, so go with it.] I took the test in PHP and it was very straightforward.

Now, perhaps my error was at this point. Perhaps I should have done it in the Javascript setting hr offers - which is Node.js. I have been taught some vanilla Javascript, and for the kind of problems hr provide it would have worked fine. I was put off by the block of code provided in the Node.js option - I haven't yet dealt with Node at all, and didn't know what this chunk of code was representing in the hr environment.

Still, I double checked the job ad and the email I'd received inviting me to test. "Any language", and no note in the email to say the languages would be restricted from the hr standard.

Well, you guessed it. They knocked about 30% of the available languages off for the company's actual test; and PHP was one of the ones to go. I lost a half hour working out how to get my FizzBuzz (which took all of 3 minutes) to output in Node and considered giving it up as a lost cause, but did eventually get it sorted. Annoyingly I then had a time shortage and questions 2 and 3 got pseudocoded and no more than that.

I'm under no illusions about how my result will be scored; if the code doesn't pass the hr test cases, it doesn't matter what happened, you don't get the points.

At the start of the test I was assured I would have a chance to give feedback at the end. Maybe they sensed my mood because I didn't ever get to a feedback screen; just the company's global homepage. Insult to injury...

I'm irritated by the way the whole thing was presented, and I'm irritated that my "base knowledge in any language" didn't actually help me here when any language didn't mean that. However, if nothing else, it was very good practice.

More so, I am wondering just how out of favour PHP is if it's not even in the top 15 language choices for entry level assessments like this. I understand that I've learned it within my course for more than the obvious reasons; I've learned it in a way that will help me learn other programming languages in the future.

My question is - should that future start right now? Is this likely to be the case on most generic assessments? Shall I set myself to learn Python before I even consider applying to a grad scheme elsewhere? What is the general opinion on PHP - is it dying out?

Group project time - javascript in a bootcamp scrum team

jennymegan — Fri, 16 Oct 2020 10:46:57 +0000

The past fortnight has been Javascript fortnight. Not that anyone alive ever learned javascript in a fortnight. Let's just say we put our toes in the pool.
It was also the first point at which we had to work on a team project. We've learned the theory of Scrum, we are all accredited scrummasters. Now we get to practise.
The task was relatively straightforward. We were building a javascript game. There are eight of us. We were to work as a single team.

My takeaways from this week are as follows:

Git auto-merge is a privilege

In our solo projects, it was very rare for one branch to conflict with another when merging. Lovely. Now, with 8 of us - mostly programming in pairs - auto-merging became a thing of the past.
I miss it. Having said that I do sincerely hope that as we get better at structuring our workload and stop poking at tasks ahead of time, we'll have less conflicting code and an easier time sorting it out. We seriously underestimated the amount of time it would take to do the reviewing of code and the merging of branches: every day is a learning day!

More is more, until it's not

Working on a project solo gave us complete control and complete responsibility. One the one hand, empowering, on the other hand, terrifying if you couldn't work out a gnarly problem. (nb. of course we can ask for help and advice but it's on us to do so).
Having the freedom now to pair programme individual tasks meant that you had two heads working on it; and as we're all learning at our own rates, often you'd tap into the other person's knowledge and sort out the error much quicker. Three people worked too; especially if the two of you had written an in depth piece of code and could no longer see past it. A third person "flying by" would sometimes pick up structural issues.
More then three in a zoom room and things started to go awry. Zoom likes to arbitrarily mute people when someone else is talking. Sometimes you lose half a word, sometimes you're just not heard at all. Some people felt totally overwhelmed by the number of bodies watching them. More people meant more dissention in syntax style (which bit us on the behind when we needed to consolidate code later).
There were even times when the entire team was asked to make a decision on something; and rather than making everyone feel included this tended to make everyone feel isolated when only a couple of voices were heard.

Personal ambition is the enemy of team health

I saw a copy of Nike's famous "10 Maxims" recently. One of its points expounded the "danger" of personal ambition. This didn't make immediate sense to me, but once I overlaid it on the team based experience of this last week, it became very clear. Some of us came into this off the back of two solo projects which had gone well: been completed to deadline with all stretch goals reached. Not all of us work at the same rate, and not all of us place the same weight on different parts of the job. Someone who is dead set on finishing quickly, because that's their personal goal, will be a source of frustration to other team members who want to take their time over the design and layout of the game. And vice versa, someone who sets great value on the "look" of the game and can lose hours moving things back and forth will be a frustration to someone who would prefer to spend that time refactoring code.

Communication is even more important than you think it is

and this holds true for technical stuff (like all of you agreeing at the start whether you want to use camel or snake case) as well as personal stuff - like not treading on people's toes when they're halfway through a task and you think you might know better, or checking in on a team member who has been particularly quiet that day.

Come sprint review you'll be pleased to be part of a team

Presenting work solo is sometimes bone-chillingly nerve wracking: presenting as part of a team gives you the chance to hghlight the good work donw by others and feel proud to have been a part of it without the underlying guilt about potentially "showing off".

The next fortnight again holds a team project although of a very different nature: watch this space.

Scrum Style, Baby

jennymegan — Tue, 15 Sep 2020 15:41:19 +0000

In my previous life I was a project manager. It was a small company and we didn’t subscribe to a particular management format. The one time I did have professional input (a 1 day course run by an independent, self-styled “management guru” who openly deemed himself unemployable) he was quick to slate both PRINCE2 and Agile.

From a distance both of them have unintelligble jargon which seems off-putting and makes them vaguely mysterious. Now, learning more about Agile Scrum as part of the bootcamp I attend, it feels more like the opposite.

All the little meetings I had to have now have specific names. There are rules and guidelines for what happens within them and the human side of the team is understood - ie. it’s entirely possible that a room full of people on a rainy Monday morning during a tough project might not want to communicate with each other. This is anticipated and planned for.

The management of a project in the past for me also involved managing the people; and that was not my favourite thing. In a small business you can become “HR” very quickly just by being a woman. [Opinion my own.] It was exhausting and distracting. This morning I spent learning about the role of the “scrum-master” in Agile software development teams; it wasn’t until the trainer spelled out that:

"The scrummaster has no authority over the other team members; their job is to make the environment as conducive to work as possible and allow team members to work to the best of their ability"

that I relaxed and realised that a) I wasn’t worried about having to potentially be scrum master at some point, and b) I was rather looking forward to having one.

Small businesses have many benefits in flexibility and cameraderie; but often a lack of budget, time, or insight into strong management practices. I think after I “graduate” at the end of the year I will be applying to large companies in the hope I can experience a more sophisticated management and working team style than the one I’ve come from.

Do you work in an Agile team? Do you recommend it? Or is there a previous job where you felt that they got it right in terms of management style?

Sunday Night CSS

jennymegan — Sun, 06 Sep 2020 19:12:00 +0000

Here we are on a Sunday night, and I'm undertaking a tedious task - trying to draw the HTML5 logo (above) using pure CSS and no images.
As someone with a background in CAD and at least a basic grasp of photoshop, it feels like having both hands tied behind my back and painting a picture with my toes...
Having said that, the task has done what it set out (I hope) to do, and I am infinitely more comfortable with CSS's graphic potential than I was this time two days ago.
It seems that even though CSS's primary use was never intended to be for making colourful shapes, there are enough little loopholes in it that some clever folk started making punchy little elements in an array of shapes.
You have the 4 bordered edges of a traditional "block" shape which can be manipulated to form triangles and trapeziuses, standard squares with "transform" to make rhomboids and diamonds, the radius property to make circles and soft edges.
Then you have the option of using an element's inherent pseudo-elements ::before and ::after to give extra little details, make more complex shapes by overlaying the originals, or even whole new shapes.

https://www.popwebdesign.net/drawing-unconventional-shapes-with-css.html is a great visual explanation of border-based and shadow-based shapes.
CSS-tricks has a good article with examples on using ::before & ::after: https://css-tricks.com/the-shapes-of-css.
And this lady just has fabulous skills as a CSS artiste: https://blog.prototypr.io/how-i-started-drawing-css-images-3fd878675c89.

Is there any real merit in designing shapes purely in CSS? Would it be an indication of a sub-par dev if I was to import images I had drawn in photoshop and place them on a site? I can see it's good to know and useful on occasion (to overlay a "Sale" sticker or similar) to use the CSS, but surely when making graphics using an intuitive graphical interface like photoshop (or even trusty old MS paint) has to be the best option. Open to opinions!

Pair programming...or not?

jennymegan — Thu, 03 Sep 2020 18:14:05 +0000

Week 1, Day 3 of bootcamp.
To get us used to working in industry standard practices this afternoon we coded a form (yes, it was basic but the content wasn't really the point of the demo, and hey, I'm only three days in) with a partner.

Now, that would be stressful enough given that I've only known my partner for three days and yesterday I thought he was someone else (oops) - but we're doing this through perspex. Thank you, Covid. Turns out as well as being spit-proof it is surprisingly soundproof. We bellowed at each other for quite a while before lapsing into a sort of poor quality sign language. What we produced was adequate, but neither of our finest works.

My immediate reaction to the concept of pair programming is horror. The beauty of coding is in not having to deal with other people, right...? Wrong. Turns out I can't just hang up my social skills on the way in the door. I can see that two heads can be better than one. I get that. But is the pay-off worth the process? Does anyone have any stories about how this goes in their workplace?

Do you pair sometimes, on certain projects, or more frequently?
Do you always pair with the same person?
Do you CHOOSE the person you pair with?
Have you paired with someone who was lazy - or a smartass?
Does it ever stop being fundamentally awkward sitting very close to a colleague and reading over their shoulder?
In your opinion, is it a good practice and one you'd seek out in a new job?

Bootcamp in the time of Covid

jennymegan — Wed, 02 Sep 2020 18:35:42 +0000

Week one, day two of my coding bootcamp. I won't refer to it by name because I'll probably end up coming across as a plant... If you're interested enough it won't take much digging to find where I'm attending!

It's been an intense couple of days. I'm coming out of a career in yacht interior design, and the contrast here is stark. Seven years of managing projects in which ultimately I had no control over the crafting of the actual pieces - traded for four months of learning to make, by hand, pieces of work in a different format.

I like control. I like being accountable for my own work. It has been years since I've been intellectually challenged in the way that I think this course is going to do and I can't wait.
I was a nerd in school; my favourite things were Maths and Latin. I hid in the library during PE and managed to go my whole school career without a single cross country run. I left sixth form to study Physics and then decided after a year of it that I wanted to break out of that "nerd" box. I switched course, moved, and ended up taking an unrelated arts degree.

Ten years (ish...) on, and I was chugging along in the design world. But something was missing. I applied to two bootcamps, figuring that their in house assessment process (necessary to maintain their professed 99% post-course hire rate) would give me a good indication of whether I'd be able to complete. I got in to both and chose my favourite. This was in June 2020 - peak lockdown. I had plenty of time on my hands whilst work was slow so I started some Codecademy courses (Javascript, PHP, Bash, HTML & CSS). I worked on them every damn day for the three months between getting in to the bootcamp and starting - driven partly by curiosity and partly by fear. Two days in and I am so grateful that I did. The gulf between the people who prepped for this and those who didn't is already apparent, and all we've done is basic HTML & CSS styling.

Next week we apply this to build a skeleton portfolio website; the idea being we fill it with all the projects we make between now and Christmas. I'm excited like a small child.