[Closed] Software Engys, Programmers, anyone who codes!

What are you struggling with?

Following the logic? The language? General concepts? Design?

It can be difficult to learn something while trying to deliver at the same time, learning often involves going back to the start rather than going forwards. If its a new language I usually try to buy a book and read it when I have time as I always find that better than online learning. Books usually seen better thought out

If they are not providing any training then if I were you I'd consider approaching your project manager, expressing your concerns and asking for a mentor or programming buddy. (Not unusual, especially with new engineers).

I switched from civil engineering to software development over a period of years, id say I was productive from the start but I had a lot of very good help.

I do think that programming is something you get or you don't.

What languages and frameworks are you using? You will need to know the syntax (if/loops/logical operators) the libraries (how to read write to astream) and the frameworks - these depend on the language for Java for example they would be JUint,Hibernate, Spring/EE

You would also benefit from knowing about the design patterns for the manages you are working with. Try and find a book that covers the GoF patterns with examples in your language.

There are on line resources that can help such as Linda.com and stack overflow. You can also try reddits such as r/programming and r/lean programming where you can work through problems and be critically assess.

As you mention sprints I'll assumed you are using Scrum, many you could suggest doing some pair programming - this is another agile methodology here you and a coworker said a computer to work on a problem together.

And based on STW it helps if you are called Graham

If they are not providing any training then if I were you I'd consider approaching your project manager, expressing your concerns and asking for a mentor or programming buddy

This +1, I can see it being quite a frustrating experience if you are getting no support. It would be odd really, given the situation you describe for your team/management to not expect to need to provide this. Even with experience, other peoples input is a useful thing.

As for how long to know if you will "get it" - I think I've been doing to too long to be able to offer an opinion!

Ignore him. He's the early Alpha release.

TheBrick - Member
What are you struggling with?

Following the logic? The language? General concepts? Design?

I don't think I have much problem with the language I use. It seems to be translating what is expected from my particular implementation into actual software.

I think a very general process for me is: Try and progress, fail, try and fix + try and attempt different solutions to the failure (seems to be where the bulk of my time goes), give up and ask for help, someone comes and shows me where I was wrong, then instantly hit another problem and the cycle continues. I just don't seem to get much success/satisfaction.

leffeboy - Member
It can be difficult to learn something while trying to deliver at the same time, learning often involves going back to the start rather than going forwards. If its a new language I usually try to buy a book and read it when I have time as I always find that better than online learning. Books usually seen better thought out

I don't know whether I can apply this properly, though thanks for the help. I think I'm lacking in software design principles (e.g. do this this way because its the most efficient), as opposed to 'you can do this this way in Java'.

As you mention sprints I'll assumed you are using Scrum, many you could suggest doing some pair programming - this is another agile methodology here you and a coworker said a computer to work on a problem together.

I think this would most definitely help me, my colleagues are quite old school with their development but I think I need to try and push this next sprint planning.

GrahamA - Member
And based on STW it helps if you are called Graham

I was expecting that response to be from GrahamX.

Yes, it doesn't have to be actual pair 'programming' either - the phases of the process that most benefit from the pairing are

1. the analysis of the problem and the break down into 'use cases'
2. the determination of what to test and how to test those use cases - preferably automatically
3. the solving of any problems/bugs

If you are struggling because you don't know enough of the product/frameworks you are using/design principles involved/toolset used, then you could suggest that you pair up with people to participate in one of the above activities instead of coding, which should help you contribute to the deliverables, whilst you catch up on areas that you are less familiar with.

If you don't feel that you have enough domain knowledge to contribute then consider a temporary transfer to QA (it is always useful to have less familiar people who are likely to 'break' stuff) or even to operations, to learn more about the domain.

At most a ticket should probably take 3 weeks - depending on your sprint cycle - and taking 7 means either that you are really struggling or the ticket scope is too large and/or not defined enough. A non-requirements ticket will normally only cover a use-case which should be well defined.

We've found pairing to really help people learn on a project, that being said I do have a team who can be good at sharing information and skills when the time comes.

The advice here is as good as you'll get elsewhere, raise to your Scrum master/PM and try as much as you can yourself then get help. It is also important to learn from your colleagues as opposed to asking the same question over and over.

When it comes to coding approach problems - StackOverflow is your friend 🙂

I will say, having done some teaching in CS in a university (and from my own experience) some people "get it" and some people don't. Those that don't can muddle through, but it's always a struggle for them.

What are you doing to learn? Just your job, or trying your own projects on the side?

I interview a fair few engineers (both grads and senior level), and I firmly believe that it is something that requires a particular mindset to be competent at.

If you are struggling to learn a language, framework, syntax or design pattern, that is something that will come. If you struggle to produce logical, simple code, then I'm afraid that you will always struggle.

If you don't love the coding, then modern software development has many other roles (such as testers, project managers, business analysts) which all used to be the domain of the software engineer and have now become seperate roles. They are all equally rewarding career paths.

interview a fair few engineers (both grads and senior level), and I firmly believe that it is something that requires a particular mindset to be competent at.

I think some people call it a "spectrum". 😉

I think some people call it a "spectrum".

They are all equally rewarding career paths.

!!!

what does

a = a + 1

mean to you ?

apparently those that think it looks wrong (as it it blatantly not true) will probably have problems with programming.

I think the mindset is being able to break down a problem into small steps. This is something that people do in everyday life as much as in development. My wife for example has never written any code but she approaches any practical challenge in exactly the right way.

I'd say that fixing problems in existing code (or making small enhancements) is quite hard for an absolute beginner, because you have to understand how the existing system works. If it's badly written or complicated, you'll be in a heap of trouble; if there's little useful documentation it'll be worse. I'd be asking for some basic courses on software design, rather than language use specifically.

When faced with having to figure out how a complicated system works and fix issues, I reach for my imaginary deerstalker hat and become Sherlock Holmes. You have to deduce what's happening from the evidence available, just like Holmes. It's not easy, for sure, but being methodical and logical helps.

apparently those that think it looks wrong (as it it blatantly not true) will probably have problems with programming.

Not sure that's true - those who think it looks wrong probably have a maths background - once you tell them that = is an assignment operator it makes sense!

A better test would be to ask someone to give instructions on how to make a cup of tea, and be as specific as possible... see what they come up with. But this doesn't help the OP as that's all about designing code, not fixing someone else's.

Re pair programming - the experienced person has to have the right mindset to teach well, which is another aptitude altogether 🙂

"spectrum" - ha ha I think I worked with the bulk of those in my day!!

pair programming can work but if the guys are old school they may not get it, or have the mindset, or be at the right time (I know I felt a bit like that sometimes).

Get one little thing working - in isolation, in a test bed - and program the hell out of that - make it work, make it fail, make it faster, more readable, more reliable - then move on. With mentor of course. I learnt a lot from a couple of very helpful guys. Some were as above a bit fearsome though.

Callum (sorry, Graham...)

oh, and I find myself in a testing (as in program test) role as much as dev. these days, coming from a dev. background I find it helps, and the same skills and er attributes can work equally well for testing as for coding..

I suppose that's where TDD has its strengths, possibly.

So what are you actually doing? I think you mentioned Java, but perhaps if you could add a bit more detail we could give you a few pointers about things you could read up on?

I suppose that's where TDD has its strengths, possibly.

TDD has lots of strengths but one of them is obviously emphasizing the test aspect (!).

I heard a colleague trying to come up with a 'definition of done' guide for when a ticket is complete, and there was a peer code review in it.

I pointed out that this didn't fit with the agile/XP model of TDD, where the importance is defining tests that cover the functionality required for the next deliverable, and then you make all the tests work in time for the next deliverable.

If something has to be coded up in a non-optimal way to meet the deliverable then it doesn't matter - the importance is that the test works.

Once delivered you then refactor to make the code better, before you build on it again - otherwise the entropy of the system will increase.

If a code review at the end pointed out that you had done it the wrong way or that the code was iffy, then so what? Any code review is at the start of the next phase, probably with your pair as you design it.

A lot of the value of a system is then in the tests, which are often named in a way that makes assertions about how the system works, which also helps document the system. Newbies can see the assertions, and also trace through the tests to see how their solution was implemented.

it sounds like you have a very nice boss.

you say:

I can't see my skills developing

it's easy to fall into this mindset when your head is not in a good place.

are you making the same mistakes today as you were a year ago? - or are you making brand new mistakes?

if it's the latter, that sounds just like my experience of coding.

(almost, the more I learn, the more complicated the mistakes)

A Pluralsight membership is a good option - the more expensive opton lets you download courses to your tablet which you can watch on the commute (unless you are driving...) and has exercise files.

One advantage is being able to flick back and rewatch portions, in case you don't get it first time or weren't concentrating fully.

They are only really a higher level overview - you would need to read a book to get more indepth knowledge, but as long as you practise what you have watched then they are good.

@TurnerGuy, I agree entirely on the "tests are the specification" aspect of TDD - I suppose I was trying to get across that if you are analytical, and have come from a coding background, then testing - and writing tests - becomes almost second nature, the picky aspect at least - what happens if I do *this*, boundary cases, really esoteric scenarios.

I suspect a good deal of lawyers are "spectrum" as well - I certainly suspect my dad was - all those legal special cases, it's like code in words 🙂

I had to sit an aptitude test when I got my first software development job. Out of a room of 100 people only 2 people passed the test.
Have you been on any basic software design courses i.e. language independent?

I agree entirely on the "tests are the specification" aspect of TDD

Only if the design part is done well.. like many of these ideas it only works well if everything else is done perfectly.. which is rarely the case in my experience.. and you end up wasting a lot of time.. in my experience problems with projects are rarely due to implementation bugs in specific sections of code.

Remember that projects vary enormously. A lot of these methodologies seem to come from the USA where the working practice and even the scale of projects is quite different. People seem to read the blurb and decide XYZ is the best way of doing things, but what's best varies hugely depending on the project situation. There is no 'best', only the right way in the right project at the right time. That's why there are so many approaches.

But this is a hijack, so please accept my apologies 🙂

Out of a room of 100 people only 2 people passed the test.

here's my aptitude test - does this code work, and if not why not (ignore any syntactic errors) :
[pre]
public class Node
{
public int _value;
public Node _nextNode;
}

public class Test
{
public static Node insertNodeInSortedSingleLinkedList(Node firstNodeInList,
Node newNode)
{
Node currentNode = firstNodeInList;
Node previousNode = null;

while (currentNode._value < newNode._value)
{
previousNode = currentNode;
currentNode = currentNode._nextNode;
}

previousNode._nextNode = newNode;
newNode._nextNode = currentNode;

return firstNodeInList;
}
}
[/pre]
Seems to work pretty well for me, rooted out some major bluffer in the interviews (knew all the terms, etc) and highlighted some pretty quiet and/or inexperienced people that turned out to be really good.

Answers about using frameworks to do this stuff are missing the point. I normally make sure the candidate is comfortable with what a singly linked list is and also what the problem is - find the point in the list at which to insert the node (as the list is sorted - as in the method name) and then adjust the links.

Pretty reasonable test I'd say*. Bit easier than FizzBuzz 😀

(* I know the answer but as I'm not the target audience I won't spoil the fun for my own ego just yet)

Not keen on that kind of aptitude test TurnerGuy. You don't need a roomful of nitpicking geeks on a dev team 🙂

When asked if a piece of code works, my first instinct is to run it and see. If it doesn't, I put breakpoints or diagnostics in until I narrow it down to a certain point. I don't see the point in stepping through it in my head when the computer can do it a lot faster and more reliably.

I'm very good at finding and fixing defects in real life, so it's frustrated to be rejected based on what is essentially purism.

The answer is pretty simple and logical - you test for a median case and two limits - beginning of list and end of list.

You can also consider an empty list and a null newNode if you want.

So you can choose suitable values and walk through the code to prove or disprove it, or you can just identify the unit tests you would write to test the method.

So it's still a pretty relevant question imho.

Not keen on that kind of aptitude test TurnerGuy. You don't need a roomful of nitpicking geeks on a dev team

When asked if a piece of code works, my first instinct is to run it and see. If it doesn't, I put breakpoints or diagnostics in until I narrow it down to a certain point. I don't see the point in stepping through it in my head when the computer can do it a lot faster and more reliably.

Yep, seen your comments before and pretty sure you wouldn't get my selection...

Nit picking geeks is completely not the point of the question.

Identifying people who seem scared of getting their hands dirty and walking through some pretty simple code is - as has happened here 🙂

Walking through framework code - and in walking through disassembled code - to find a problem is a lot more of an ask.

And in the modern world if you find a piece of code that doesn't work you then identify why your tests didn't highlight it, fix the test, and then fix the code. Otherwise someone else could break it again in the future and you wouldn't catch it at build time.

I put breakpoints or diagnostics in until I narrow it down to a certain point. I don't see the point in stepping through it in my head when the computer can do it a lot faster and more reliably.

Depends on the job. We do a lot of embedded stuff and don't always have access to fancy-schmancy breakpoints, debug output and the like.

Plus a test like that shows you know where the likely failure points are. Depending on the inputs you could run through that code in your IDE (or unit test) and it would work just fine, but by reading it I found an error faster than it takes my IDE to launch. 😀

here's my aptitude test - does this code work, and if not why not (ignore any syntactic errors) :

Before looking at the code, I'd want to know what you mean by "work" and what the code is supposed to do. If it's a routine to translate French into Klingon then no, if fails quite catastrophically.

Yep, seen your comments before and pretty sure you wouldn't get my selection.

You think I'm not good at my job? Could it be that my approach is just different?

Identifying people who seem scared of getting their hands dirty and walking through some pretty simple code is - as has happened here

You would seem to be a worse interviewer than I am a developer 🙂

And in the modern world if you find a piece of code that doesn't work you then identify why your tests didn't highlight it, fix the test, and then fix the code

Aye, if you're working in an environment with a comprehensive set of unit tests, and IF the defect was caused by logic and missed by poor unit tests.. that's usually not the case in my area and experience. Defects in my line of work are usually caused by poor specification, analysis and communication. That line of work incidentally is Enterprise Java.. interested to know what yours is?

By the way, I've stepped through tons of code, I'm not afraid of it. I have decompiled code, stepped through it, found the line and emailed the vendor's support with a fix. However I've also found defects in products by deduction without seeing any code, which stumped everyone else. In fact it's my favourite part of the job. I love being brought in when no-one else can fix the problem, cos I always can 🙂

Before looking at the code, I'd want to know what you mean by "work" and what the code is supposed to do. If it's a routine to translate French into Klingon then no, if fails quite catastrophically.

it's in the method name...

You would seem to be a worse interviewer than I am a developer

if the candidate is struggling even after I have explained what the linked list is I then start walking through the median case, selecting values for the list and drawing it out, selecting a newNode value and inserting it into the list at the right place, with the links redrawn. etc.

If still no go I walk through the code for the median case, giving the candidate every chance to realise the need to test the edge conditions (beginning and end of test).

Basically as much hand holding as I can in case he is code-blind or suffering from some other interview-induced stress.

But some candidates just can't seem to cope with it - but if they are phased by this then how would they cope with the need to locate a bug quickly under pressure and produce a reliable fix...

I had one guy who seemed to talk the talk and know all the terms, etc, who then proceeded to tell me the variable names were poor and he would rename them to things like a1 and a2!

Sorry mol, but if you can't spot the fairly obvious flaw in what amounts to six lines of effective code then I wouldn't hire you either, because you may be a whizz at debugging in an IDE but how are you going to perform code reviews or write correct unit tests (both of which should, if done properly, spot the error).

I don't doubt you are good at [i]your[/i] job, but development practises vary so it's quite reasonable for TurnerGuy to say you wouldn't suit [i]his[/i] job.

who then proceeded to tell me the variable names were poor and he would rename them to things like a1 and a2!

It's faster you see, because the computery thing doesn't need to spend so much time reading. 😉

Sorry mol, but if you can't spot the fairly obvious flaw in what amounts to six lines of effective code then I wouldn't hire you either

I have deliberately not read it 🙂 I am saying that I don't like that kind of test. Of course if it's that easy then perhaps it's not so bad, I don't know.

it's quite reasonable for TurnerGuy to say you wouldn't suit his job

Possibly true yes. One thing I don't like is geek dogma.

it's in the method name...

You'd hire a developer who trusted the method name as a reliable means of determining what the method was supposed to do?

interested to know what yours is?

would have to hook out my cv to be precise but it would be approx 10 years C, 12 years C++, 6 years C# and some Java in there as well. Lot of async/multithreaded experience.